Attachment lookup cache can exhaust frontend request memory

[pirate-bot]

Summary

Frontend image processing can terminate with an allowed-memory-exhausted fatal while resolving attachment IDs.

Expected behavior: Processing a page with many distinct image URLs completes within the request memory limit.

Actual behavior: The request can exhaust its memory limit during attachment-ID lookup.

Impact: Affected frontend requests fail before page output is completed.

Customer context

• Product / area: Optimole attachment-ID lookup used by DAM/media offload processing
• Version: 4.2.11
• Environment: WordPress 7.1, PHP 8.1.2; 128 MB PHP memory limit reported
• Integration / third party: Not provided
• Reported error / symptom: Allowed memory size of 134217728 bytes exhausted at the attachment-ID lookup call
• Impact: 8 occurrences across 2 production sites in the telemetry window

Reproduction notes

Reported production workflow: a frontend request on Optimole 4.2.11 reaches attachment-ID resolution and exhausts a 128 MB PHP memory limit.

Reproduction has not been run locally. A likely reproduction is a frontend response that causes media-offload URL processing for many distinct image URLs in one PHP request.

Diagnosis

Conclusion

The release code keeps each distinct attachment-URL cache key in Optml_Attachment_Cache::$cache_map for the lifetime of the PHP request and provides no size limit or automatic clearing path. The crash occurs at the call that enters this cache during frontend image processing. This is a confirmed unbounded per-request memory-growth path; the telemetry does not reveal the number or shape of URLs required to reach the reported 128 MB limit.

Where this likely occurs

• inc/traits/dam_offload_utils.php — Optml_Dam_Offload_Utils::attachment_url_to_post_id() lines 284–332 calls the cache for each input URL, then caches the lookup result.
• inc/attachment_cache.php — Optml_Attachment_Cache::get_cached_attachment_id() lines 27–40 inserts a value into the request-static $cache_map for cache misses; set_cached_attachment_id() lines 51–62 also inserts into that same map without a capacity boundary.
• inc/url_replacer.php — Optml_Url_Replacer::is_offloaded_url() lines 430–450 reaches attachment_url_to_post_id() while processing an offloaded source URL.
• The same cache behavior is present in tag v4.2.11. Git history attributes the cache lookup to 4c726ce1 (fix: cache calls to attachment_url_to_postid); no inspected tag comparison establishes a previously working bounded implementation.

Engineering notes

The cache is intentionally request-local, as documented in Optml_Attachment_Cache::get_cached_attachment_id() around lines 29–38, so it is released after a normal PHP request. Its growth is nevertheless proportional to the number of distinct processed URLs in a single request, including negative cache lookups. The affected frontend path can be reached when media offload is enabled through Optml_Url_Replacer::is_offloaded_url(). The available shutdown fatal lacks request HTML and a structured stack trace, so the exact page size and URL diversity remain unknown.

Test coverage status

tests/test-media.php covers normal attachment lookup variants in Test_Media::test_replace_alternative_domain() around lines 483–498 and resets the static cache before editor-content tests around lines 499–563. No relevant coverage was found during inspection for a large number of distinct attachment URLs in one request or for a memory-growth bound.

What to verify or explore next

• May be worth reproducing frontend replacement with media offload enabled and a page containing an increasing number of distinct local and non-local image URLs under a 128 MB memory limit.
• If reproducible, checking the peak size of the request-local attachment cache and whether cache misses contribute materially would close the telemetry context gap.
• May be worth running the targeted tests/test-media.php suite alongside a volume-oriented lookup scenario.

Unknowns / follow-up

• The telemetry has no structured stack trace or request payload, so the exact caller and number of distinct URLs at failure are not known.
• No release boundary proving a regression was identified.

Confidence

Confidence: 87/100

One confirmed Optimole defect explains the DAM lookup memory-exhaustion fingerprint: the v4.2.11 release retains every unique attachment lookup in a request-static cache without an eviction boundary. The other four fingerprints do not currently establish a shipped defect: both required target files exist in the tagged release and match the autoloader path, the reported output-buffering location does not contain buffering calls in the locked SDK source, and the SDK-start memory fatal remains limited to one site without a trace showing an unbounded SDK allocation.

Crash telemetry

Occurrences	8
Distinct sites	2
First seen	2026-09-05 21:28 UTC
Last seen	2026-09-06 16:55 UTC
Crash location	product:inc/traits/dam_offload_utils.php:285
Request context	frontend
Inside Themeisle SDK	no
Product versions	4.2.11
WP versions	7.1
PHP versions	8.1.2-1ubuntu2.25
SDK versions	3.3.61

---

Source: automated crash report — optimole-wp, fingerprint a031c89fdc3708fad35d577ae2cf94df
Generated by bug-report-triage (ID: bug-report-triage_6a9e53b43c3721.46530364)