AI Settings Saved Without The AI Permission - edmozley/freeitsm GitHub Wiki

AI settings could be changed without the AI permission

Fixed in 3.8.0. Present in every release from 1.0.0 to 3.7.0, in Forms and in Workflow. Found while building #180 (which separates who may design forms from who may approve them), not reported by anyone.

What you saw (or, more likely, didn't)

Nothing. Forms → Settings → AI and Workflow → Settings → AI hold the AI provider, the model, the address the requests go to and the API key. The tab itself was only shown to people with that module's AI settings permission, and its Test button refused anybody else. But the save behind it checked only that you had the module. So any analyst with Forms or Workflow could replace the key, or point the AI requests at an address of their choosing - and the form and workflow text sent to the AI would then go there.

What was wrong

Two endpoints sit side by side in each module. The test one carried the permission check; the save one, written at the same time, did not:

// api/forms/test_ai_key.php
requireModuleAccessJson('forms');
requireCapabilityJson(Cap::FORMS_AI);

// api/forms/save_ai_settings.php, before 3.8.0
requireModuleAccessJson('forms');
// ... and straight on to saving the provider, endpoint and encrypted key

api/workflow/ had the same pair with the same gap. Hiding the tab made it look guarded; only the server decides.

The fix


The save needs the permission	`api/forms/save_ai_settings.php` requires `Cap::FORMS_AI`, and `api/workflow/save_ai_settings.php` requires `Cap::WORKFLOW_AI` - the same check as the Test button beside each.
The guard cannot fail open	Both now load `includes/rbac.php`, where `requireCapabilityJson()` lives, so the new check cannot fail on a function that was never loaded.
The next one is caught	Debug tool D005 (System → Debug Tools) now flags any settings endpoint that saves an encrypted secret behind module access alone.

📁 Files: api/forms/save_ai_settings.php · api/workflow/save_ai_settings.php · system/debug-tools/D005_endpoint_permissions.php · tests/security-findings/run.php

How it was proved

Over HTTP: an analyst with Forms and Workflow but no AI permission was refused (403) by both saves. An administrator got past the check (the control). The test payload was deliberately invalid, so nothing was written either way.
In the security suite: check F11 fails if either save loses its permission check or its rbac.php include, with the Test endpoint's matching check as the positive control.

What this means for you

Upgrade to 3.8.0. Then, if analysts who should not have had it use Forms or Workflow, open Forms → Settings → AI and Workflow → Settings → AI and check the provider, the address and the key are still the ones you set. If you are not sure, enter the key again and press Test.