Security Inquiry – PHP Vulnerabilities CVE-2026-109618 and CVE-2026-109619Answered

Hey Thomas,

Could you please confirm whether any of wyDay's licensing and activation services are affected by these vulnerabilities?

Short answer: no.

Medium answer: TurboActivate and TurboFloat are machine code (not interpreted language like PHP, Python, etc.). They would never be affected by this.

But as always: use the latest version (currently 26.x) to get all the latest improvements and security fixes in this machine code.

Longer answer: we use PHP to develop server-side functionality. However these bugs are nothing-burgers. They only really affect sites that were so open to manipulation (un-restricted inputs, arbitrary uploads, no proper HTTPS-server-level filtering, etc).

We moved off the affected versions of PHP the moment the fixed release was out. However, we could still be running the previous versions with these 2 “security” bugs and be unaffected. Why? Because we've designed our systems to filter and reject malicious inputs before they have the chance to explode memory, etc (all the preconditions needed to exploit these bugs).

There was a lot of breathless coverage of these bugs, but for well-implemented systems there's no way to exploit these bugs. Despite what “ai” slop-machines might extrude out claiming otherwise.

They were really bugs. And they might have affected real websites for poorly implemented systems, so it was worth the fix and the news around the fix.

The downside is there's a lot of “Ai”-slop (and human slop) that purports to have PoC code that just doesn't work (even on poorly implemented systems).

To sum up:

• “Ai” is useless garbage as usual. Slopping out nonsense for clueless script-kiddies.
• These bugs never affected us.
• We were aware of the vulnerabilities, tracked them, and implemented fixes as soon as they were available. Which we do for all our dependencies.

And, more broadly, for “AI”-slop that creeps into our dependencies we either drop-them immediately (and switch to a slop-less dependency), hard-fork them, cherry-pick-out slop commits, or keep them frozen in a state before the slop (for simple dependencies).

We take ownership of dependencies we use. That means reporting bugs, fixing bugs, adding features, and fixing security issues. A couple of large examples of this, is if you make an HTTPS request on Windows using curl or libcurl, you're using the code we contributed to curl (adding TLS 1.3 support for SChannel in curl). This includes if you use Visual Studio or git on Windows.

Or, doing a security audit and then fixing a number of bugs in the mbedTLS / curl integration.

Those are a couple of examples of us actually “taking security seriously”. Namely, doing security work proactively rather than reactively. Only with human written code. No “AI” extruded slop.

People willingly consuming “AI” slop code is a bigger concern than these PHP bugs.