OMGF Pro v5.2.8 Patches another Vulnerability — Welcome to the Jungle!

I want to talk about something bigger than a single plugin update, even though a plugin update is what prompted it. OMGF Pro 5.2.8 is out, and it’s a security release. More on that in a moment. But the real reason I’m writing a whole post instead of a changelog line is AI WordPress plugin vulnerabilities, and how fast that combination is reshaping the way every site owner needs to think about updates.

Here’s the shift. Now that AI has become genuinely capable, finding vulnerabilities in software has moved into a completely different gear. Reviewing a codebase for security holes used to be slow, specialised, manual work. A lot of it isn’t anymore. The numbers show it plainly:

Patchstack logged 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42% jump over the year before. That isn’t because WordPress suddenly got sloppier. It’s because the tools for finding these things got dramatically better, and dramatically faster.

That speed cuts both ways, and that’s the part worth sitting with. Researchers now spot and fix bugs quicker than ever, which is genuinely good news. But attackers wield the same tooling, and that has collapsed the gap between disclosure and exploitation. For the most heavily targeted flaws, attackers now close that gap in hours rather than days. The first 24 hours after disclosure carry the real danger.

AI WordPress Plugin Vulnerabilities: Nobody is too big to land on the list

If you’re picturing this as a small-plugin problem, it isn’t. Look at the plugins you almost certainly trust and run without a second thought.

WPForms, sitting on more than five million installs, has had a steady stream of vulnerabilities logged through 2025 and into 2026, including unauthenticated ones patched as recently as this spring.

Yoast SEO, on more than ten million installs, has had several stored cross-site scripting flaws disclosed this year alone, patched across a run of releases. These are two of the most established, best-resourced plugins in the entire ecosystem, maintained by serious teams with real budgets. They still show up on the list, because everybody shows up on the list eventually.

That’s the real story behind AI WordPress plugin vulnerabilities right now. A vulnerability being found is not proof that a plugin is badly built. It’s proof that someone finally looked closely. And these days, a lot more people are looking a lot more closely, a lot faster.

Yup, that includes OMGF Pro

Which brings me to 5.2.8.

Under specific conditions, someone could have nudged OMGF Pro into reading a file it had no business touching, potentially including something sensitive.

It was reported to me through Patchstack, handled as a coordinated disclosure, and there’s no evidence anyone ever used it in the wild.

The reassuring part is that this was a file read, not the far scarier remote code execution I patched back in 5.2.7. Nobody could run their own code on your site through this one.

I’m leaving the step-by-step out on purpose, because handing people a roadmap while everyone’s still updating helps nobody.

If you run OMGF Pro, update to 5.2.8. And because the worst case involved reading wp-config.php, you can rotate your WordPress keys and salts and change your database password if you’d like to be thorough. Think of it as wiping down the counter after you’ve already cleaned up the spill. It’s a belt-and-braces move, not a requirement, and for almost everyone, updating the plugin is genuinely enough.

The part I really want you to hear: read your changelogs

Here’s where the new normal gets practical, and where I want to push a little.

Get into the habit of reading changelogs before you hit update. I mean it. It used to be a nerdy nice-to-have. It’s now one of the most useful security habits you can build, for two reasons:

Supply-chain risk:

This has turned genuinely nasty. Earlier this year, an attacker quietly bought a portfolio of more than thirty established plugins. That purchase came with update access, and the attacker used it. A single “compatibility update” carried a dormant backdoor. It sat quiet for months before waking up. By the time anyone noticed, it had reached an estimated several hundred thousand sites. This wasn’t a break-in in the traditional sense. The update mechanism itself became the delivery van, because the platform trusted the new owner. Read your changelogs, and that trust gets a second check. A vague “minor fix” on a plugin that just changed hands should raise an eyebrow. So should an update that breaks the plugin’s usual rhythm. That instinct is now a real line of defense.

Timing:

This one comes with a twist. In June, WordPress.org rolled out a mandatory delay. New plugin releases now wait up to 24 hours before they reach sites. The intention makes sense. It targets the supply-chain problem above head-on. It gives the security community a window to catch a poisoned release before it reaches millions of sites. But there’s a catch that got a lot of developers talking. A release publishes its changelog and code the moment it goes live. The delay only holds back the update itself. So for up to a day, anyone scanning for freshly disclosed fixes can see exactly what the developer patched. Meanwhile, you’re stuck unable to click update. In other words, reading a changelog matters. So does updating manually when it counts. That’s no longer optional knowledge.

It’s a strange time. Stay sharp.

I’m not telling you any of this to scare you off WordPress. I make my living on it, and I still think it’s a fantastic place to build. But we’re in a genuinely strange moment, where the rise of AI WordPress plugin vulnerabilities has outrun the comfortable old “I’ll get to it next week” rhythm.

The good news is that staying safe doesn’t take paranoia. It takes a handful of solid habits: update quickly, actually read what you’re updating, keep your plugin footprint lean so there’s less that can go wrong, and lean on developers who are straight with you when something needs fixing.

That last one is on me, and it’s a big part of why this post exists instead of a quiet changelog line. That’s two security releases from me in a short span, and honestly, given where the tooling is heading, I expect this cadence to become normal for a lot of plugins, not just mine. More eyes, moving faster, finding more. I’d rather meet that head-on and tell you the truth every single time than hope you don’t notice.

A CVE identifier is being assigned through Patchstack, and I’ll add it here as soon as it lands. Big thanks to Patchstack, and to the researcher who reported this the right way.

Stay sharp out there, and thanks, as always, for running OMGF Pro.