OMGF Pro v5.2.7 Closes the Breach: A Full Breakdown of the Exploit

On June 25, 2026, a critical vulnerability in OMGF Pro was actively exploited in the wild. I’ve spent the past hours investigating the exploit, analyzing the post-exploitation payloads, and shipping a fix. Now that the dust has settled, I want to walk you through exactly what happened, what the attackers did, and how to verify your site is clean.

The fix is available now. Update OMGF Pro to v5.2.7 immediately.

How the attack worked

The exploit was fully automated. From first request to full server access: about 15 seconds.

Here’s the chain:

1. The attacker hit a site with a crafted URL that triggered OMGF Pro’s auto-configuration mode — the routine that normally runs during setup to detect which Google Fonts your site uses.
2. The URL included a WordPress search query containing a CSS @import statement pointing to a malicious .php file on the attacker’s server.
3. Most themes display the search query somewhere on the results page. OMGF Pro saw the @import in the rendered HTML and treated it as a legitimate stylesheet reference.
4. OMGF Pro downloaded the file and saved it to wp-content/uploads/omgf/ — with its original .php extension intact.
5. The attacker visited the uploaded file directly. The server executed it as PHP. Game over.

No authentication required. No user interaction needed. Fully automated.

What the attackers deployed

The initial file (the “dropper”) didn’t do much on its own. Its real job was to download and install a self-deleting WordPress plugin — innocuously named Charming Quirk — that did all the actual work.

Once that plugin had run, it erased itself, which is why first responders often only see traces of it in their logs and not the plugin itself.

This plugin is not a simple backdoor. It’s a structured, reusable deployment framework with a single public REST endpoint (/wp-json/charming-quirk/v1/check_version) that runs a four-stage pipeline and reports the results back to the attacker. And notably: it was written specifically to target OMGF Pro. One of its stages references the exact internal code of my plugin. This was not a generic attack that happened to catch OMGF Pro — it was built for it.

Here’s what each stage did.

Stage 1 — Planting the backdoors

The plugin downloaded three payloads from the attacker’s server and placed them on the site:

• wordfence-security.php in wp-content/mu-plugins/ — a fake “Wordfence” plugin (nothing to do with the real one). It gave the attacker silent admin access through a secret URL parameter and recorded every username and password entered on the login page, forwarding them in cleartext to the attacker’s server.
• sso.php in wp-content/mu-plugins/ — a fake single sign-on plugin. It registered a public, unauthenticated endpoint that logged the attacker in as admin. Chosen because it looks legitimate and is commonly whitelisted by scanners. (A variant named sso-1.php also exists.)
• A randomly named webshell, dropped into a random date folder inside wp-content/uploads/ — for example wp-content/uploads/2014/07/22/xVbdeffg.php. Note: this is not in uploads/omgf/. It’s deliberately hidden among your legitimate media uploads, in a folder with a believable old date.

Here’s the part that makes detection genuinely hard: after writing each file, the plugin copied the modification date from existing, legitimate files onto the new ones — and even onto the WordPress root directory.

This means a scan that looks for “recently modified files” will not find these backdoors. They look just as old as the rest of your site. You cannot rely on file dates to find this infection. You have to look at file contents and locations.

Stage 2 — Patching the vulnerability behind them

This is the stage that stood out the most. The plugin modified OMGF Pro’s own src/Wrapper.php, injecting a gatekeeper that blocks anyone else from using the same exploit — returning a 403 error to any repeat of the attack — unless the request carries a secret password matching a hardcoded hash.

In other words: after breaking in, they closed the hole behind them to lock out rival attackers, while keeping a key for themselves.

This has an important consequence: a site that returns a 403 error when you try to reproduce the exploit may already be compromised. Don’t treat a 403 as proof you’re safe. The hardcoded hash they injected is a reliable fingerprint — see the checklist below.

Stage 3 — Removing rival administrators

The plugin pulled the list of all administrators and stripped the admin role from any account created after a certain cutoff date — except the original site owner and their own account. The purpose: if a competing attacker had already created their own rogue admin, this kicks them out. It’s territorial. They clean up after other intruders to keep the site to themselves.

Stage 4 — Creating the rogue admin and scanning for neighbours

Finally, the plugin created a new administrator account. On the sites I’ve looked at, it used the display name “Yuna Mochi” with a username consisting of the site’s domain name followed by three random characters. It then backdated the account’s registration date — copying it from an existing user — so the account blends in with your legitimate users. It also suppressed all of WordPress’ email notifications, so no “new administrator created” message ever reached the real site owner.

In the same stage, the plugin walked the entire filesystem from the server’s root, looking for other WordPress installations. For every wp-config.php it found, it read the database credentials, connected directly to that database, and pulled the site’s URL.

On shared or reseller hosting, this means a breach on one site could hand the attacker an inventory — and the database credentials — of every other WordPress site on the same server. If one of your sites was compromised, treat all of them as potentially exposed.

It cleaned up after itself

Once the pipeline finished, the Charming Quirk plugin deleted itself — either on the next shutdown or via a 90-second timer after activation. That’s why the plugin itself is usually gone by the time anyone investigates, leaving only the backdoors it planted and a trace of its REST endpoint in the access logs.

When you’re not affected

While I still recommend updating to v5.2.7 as soon as possible, your site was likely not vulnerable to this specific exploit if any of the following apply:

• You only use OMGF (the free version). This exploit specifically targets OMGF Pro.
• Your server blocks PHP execution in the wp-content/uploads/ directory. Many managed hosting providers enforce this by default.
• You’ve disabled WordPress’ search functionality entirely.
• Your theme doesn’t display the search query on the results page.

Keep in mind, though: a clean uploads/omgf/ folder is not proof you’re safe. Because the attacker hid the webshell in a random date folder and patched the vulnerability behind them, a site can look perfectly normal and still be compromised. If you were running a vulnerable version, go through the full checklist below regardless.

A note about daan.dev

This site was not compromised. If you’re a (previous) customer of Daan.dev, your data is safe.

Kinsta, my hosting provider, blocks PHP execution from the wp-content/uploads/ directory by default, which prevented the exploit from doing any damage. This is one more reason I’d recommend choosing a managed hosting provider that enforces this kind of server-level protection.

How to check if your site was affected

If you were running OMGF Pro before v5.2.7, go through all of the following. Don’t rely on file modification dates — the attacker forged them.

1. Check wp-content/mu-plugins/ for files named wordfence-security.php, sso.php, or sso-1.php that you didn’t install yourself.
2. Check wp-content/plugins/ for a plugin folder called charming-quirk. If it’s there, your site was targeted and you should assume the backdoors below were planted — but because it normally deletes itself, its absence tells you nothing either way. Check the rest of this list regardless.
3. Look through wp-content/uploads/ for stray .php files, especially inside date folders (like uploads/2014/07/22/). Uploads folders should never contain PHP files. A search across the whole uploads directory for .php files is the fastest way to spot them.
4. Open wp-content/plugins/host-google-fonts-pro/src/Wrapper.php and search it for the string wp_pass or the hash $2y$10$EKS7KS20XuJoxuXgMyxthu.rXmhMiFyx5b/39bEbXacoLz.8ZAcve. If either is present, the attacker patched your plugin and your site was compromised.
5. Review your WordPress user list for admin accounts you don’t recognize — even if the registration date looks old. Watch for the display name “Yuna Mochi” or a username that’s your domain followed by three random characters.
6. Check your access logs for requests to /wp-json/charming-quirk/v1/check_version, or from the IP 143.110.232.91.
7. If you’re on shared or reseller hosting, run all of these checks on every other WordPress site on the same account — the attacker actively scanned for them and harvested their database credentials.

If your site was compromised

If you find any of the above, here’s what to do:

1. Remove all identified backdoor files: wordfence-security.php, sso.php/sso-1.php from mu-plugins/, the charming-quirk plugin if present, and any stray .php files in your uploads folders.
2. Restore OMGF Pro from a clean copy (delete the plugin entirely and reinstall v5.2.7), so the infected Wrapper.php is gone.
3. Delete any admin accounts you don’t recognize.
4. Change all administrator passwords.
5. Rotate your WordPress security salts in wp-config.php.
6. Change your database password and any API keys stored on the server. The attacker read your database credentials directly, so treat them as compromised.
7. Run a full malware scan.
8. If your server doesn’t already block PHP execution in the uploads directory, fix that. E.g. for Apache, add an .htaccess to the uploads directory that denies PHP execution. For Nginx, ask your hosting provider.
9. If you’re on shared or reseller hosting, repeat every step for each other WordPress site on the same account.

When in doubt, bring in a professional incident responder. Backdoors can be chained and nested, and a single missed file can re-infect everything.

Indicators of compromise

For those who want the raw fingerprints:

• Payload source: code.elemetate.com (served the dropper and the wordfence-security.txt, sso.txt, file.txt payloads)
• Attacker IP: 143.110.232.91 (DigitalOcean)
• C2 endpoint: /wp-json/charming-quirk/v1/check_version
• Dropped files: mu-plugins/wordfence-security.php, mu-plugins/sso.php, mu-plugins/sso-1.php, a random webshell in uploads/<year>/<month>/<day>/, the charming-quirk plugin, and a modified host-google-fonts-pro/src/Wrapper.php
• Patch fingerprint in Wrapper.php: the parameter wp_pass and the hash $2y$10$EKS7KS20XuJoxuXgMyxthu.rXmhMiFyx5b/39bEbXacoLz.8ZAcve
• Rogue admin: display name “Yuna Mochi”, username = domain + 3 random characters, registration date copied from an existing user
• Note: file modification dates are forged to match legitimate files — do not rely on them

What I fixed

OMGF Pro v5.2.7 addresses this at multiple levels. The plugin now validates file extensions before writing anything to disk — only .css files can be saved. It verifies that files stay within the expected upload directory, blocking path traversal. And URLs pointing to non-CSS resources are rejected before they’re fetched.

Update now if you haven’t already.

I’m sorry

I take the security of my plugins seriously, and I take full responsibility for this vulnerability existing in the first place. Your trust in my work is not something I take for granted, and I’m committed to making sure something like this doesn’t happen again.

If you have any questions or need help checking your site, don’t hesitate to reach out.