Hey there,

running Enfold 7.1.3 on WordPress 6.9 with PHP 8.2.
WordPress Multisite.

We face an issue where a site hits the OOM with 512M Memory configured when opening any Icon Font Related Avia Builder Element Popup in the wp-admin editor.

Tracing the issue down we pinpointed the SVG handling to be quite an issue regarding memory usage.

The site uses 9 Icon Fonts with a total size of ~7M. Only a part of that is actually SVG content. So let’s assume we talk about 1,5MB SVG files.

$ wp-content/uploads/dynamic_avia/avia_icon_fonts/
`
1.3M ./font-awesome-bold-01
1.4M ./font-awesome-bold-02
911K ./font-awesome-bold-03
1.9M ./font-awesome-brands
454K ./font-awesome-regular
42K ./k-iconpack01
283K ./k-iconpack02
46K ./m-icon-set-01
24K ./m-signet
`

Parsing these files lead to memory allocations of around 700MB.

Related files are “class-font-manager.php” and “class-svg-images.php” with the functions around set_svg_markup and get_icon_html. As well as followup native PHP functions down the stack trace (simplexml_load_string and substr_replace in particular).
Besides the OOM the SimpleXML calls consume about 1s alone processing time.

We identified several issues with the current implementation that could lead to this issue without being able to easily provide a “fix” as everything is quite tightly couples around the in-memory “cache” handling:

Unlimited cache: The protected $cache stores complete SVG strings without size limits → uncontrolled increase in RAM usage.

Unvalidated input loading: file_get_contents / curl_exec load entire files/responses without upfront limits → large memory spikes.

cURL without abort callback: Remote downloads can grow arbitrarily large (no Content-Length or progress checks).

String operations create copies: substr_replace, preg_match_all, str_replace on large strings increase peak memory consumption.

DOM parsing with SimpleXML: isColoredSVGWithGradients uses simplexml_load_string → the entire XML tree is loaded into memory, potentially multiplying memory usage and introducing XXE/DoS risks.

Missing size validation: No limits are enforced before parsing or caching (local or remote).

Potential format-parsing risks: Regex-based extract_svg_attributes on large inputs can be computationally expensive.

We use Datadog to create Traces and Profile of our application. We were able to confirm that the SimpleXML related code as well as the regex based ops on the SVG file content trigger the OOM in most cases.
I can easily share the Flame Graphs of the Memory Allocation and the Processing Times if you like. We find them to be most helpful in understanding what actually happens at the runtime in code :-)

The issue is reproducible for this single site so the issue will be most certainly based on the actual icon font files although they are valid SVG. So we are happy to give any fix a test before any coming release. As we operate a server cluster, just provide me the diffs / changes and we will apply and test them ourselves.

Let me know if you need any more information. I shared a link to the icon font files in the private content section.

Best Regards,
Jan