OpenAI API-key validation can exhaust PHP memory during HTTP request

Summary

Saving an OpenAI API key can terminate the request with a PHP memory-exhaustion fatal.

Expected behavior: API-key validation returns a successful result or a handled provider error within the site's available PHP memory.

Actual behavior: The validation request exhausted a 128 MB PHP memory limit while attempting an additional 10 MB allocation.

Impact: The API-key validation request fails fatally on affected sites, preventing completion of that settings workflow.

Customer context

• Product / area: Otter Blocks, OpenAI API-key validation
• Version: 3.2.2
• Environment: WordPress 7.1; PHP 8.3.33; PHP memory limit 128 MB
• Integration / third party: OpenAI API
• Reported error / symptom: Allowed memory size of 134217728 bytes exhausted (tried to allocate 10485760 bytes)
• Impact: Recorded 3 times across 2 production sites between 2026-08-22 and 2026-08-25.

Reproduction notes

1. As an administrator, submit a non-empty API key to POST /otter/v1/openai/key.
2. The reported environment had a 128 MB PHP memory limit.
3. Production telemetry recorded a fatal at the request call before a REST response was returned.

A controlled oversized provider response and constrained-memory reproduction have not been run.

Diagnosis

Conclusion

Production telemetry identifies a fatal at inc/server/class-prompt-server.php:157 in Otter Blocks 3.2.2. The corresponding Prompt_Server::save_api_key() call performs the OpenAI validation request with a 120-second timeout and no inspected response-size constraint before decoding the body. This is a confirmed product crash path. The specific upstream response or pre-existing request memory use that made the extra 10 MB allocation fail is not available, so the exact allocation source remains an inference.

Where this likely occurs

• inc/server/class-prompt-server.php — Prompt_Server::register_routes() lines 67-82 exposes POST /otter/v1/openai/key to administrators and routes it to save_api_key().
• inc/server/class-prompt-server.php — Prompt_Server::save_api_key() lines 119-187; release v3.2.2 lines 134-159 match the telemetry location, with wp_remote_post() at line 134 and the request arguments ending at line 157.
• inc/server/class-prompt-server.php — Prompt_Server::save_api_key() lines 169-170 retrieves and decodes the complete HTTP response after the request returns.
• Git history attributes the validation request to 9584265a50697bb1b76045d6fb8f87ad36145858 (feat: Add API validation step for OpenAI in Settings). No evidence inspected establishes a previously working release boundary for this crash.

Engineering notes

• The telemetry marks the request context as frontend, while the route's permission callback requires manage_options; REST requests can be classified differently from wp-admin requests, and the originating UI action was not captured.
• The OpenAI validation payload is a fixed small chat-completions request. The code path relies on WordPress HTTP handling, whose source was not present in this plugin checkout; its allocation behavior was not independently verified.
• The repository contains a newer Otter_OpenAI_Backend request path, but this report resolves specifically to the legacy Prompt_Server::save_api_key() path in the affected release.

Test coverage status

tests/test-prompt-server.php covers invalid request bodies and a mocked provider error in Test_Prompt_Server::test_save_api_key_rejects_invalid_body() and Test_Prompt_Server::test_save_api_key_returns_provider_error_status() at lines 41-88. No relevant coverage was found during inspection for a large HTTP response or constrained-memory behavior on API-key validation.

What to verify or explore next

• May be worth reproducing POST /otter/v1/openai/key against a controlled oversized HTTP response under a 128 MB PHP limit.
• If reproducible, checking the WordPress HTTP transport's memory profile for the affected WordPress and PHP versions would clarify whether the allocation occurs while receiving or decoding the response.
• May be worth confirming whether telemetry's frontend classification corresponds to an administrator REST request from the settings screen.

Unknowns / follow-up

• The telemetry has no structured stack trace, response headers, response size, or provider status.
• It is unknown whether a proxy, provider error page, or pre-existing request memory pressure contributed to the failure.

Confidence

Confidence: 86/100

One independently verifiable fatal was reported. Production telemetry locates it at the API-key validation HTTP call in Otter Blocks 3.2.2, and the inspected release code retrieves that provider response without a response-size constraint; the path has no coverage for an oversized response.

Crash telemetry

Occurrences	3
Distinct sites	2
First seen	2026-08-22 09:43 UTC
Last seen	2026-08-25 23:51 UTC
Crash location	product:inc/server/class-prompt-server.php:157
Request context	frontend
Inside Themeisle SDK	no
Product versions	3.2.2
WP versions	7.1
PHP versions	8.3.33
SDK versions	3.3.58

---

Source: automated crash report — otter-blocks, fingerprint 566765a1d4d929ea7ac637e34219b54d
Generated by bug-report-triage (ID: bug-report-triage_6a8e8142316885.05834776)

Start in inc/server/class-prompt-server.php at Prompt_Server::register_routes() and save_api_key(), especially the wp_remote_post() call and response decoding around lines 134-170. Review tests/test-prompt-server.php and run the existing invalid-body and provider-error tests before investigating a controlled oversized response under a 128 MB PHP limit. Done means the POST /otter/v1/openai/key path no longer fatally exhausts memory and its handled-result behavior is covered by tests.