CVE-2026-72559

Parsedown's safe mode is opt-in by default, and that design decision has created a persistent vulnerability class that keeps reproducing across the PHP ecosystem. The core problem isn't a single developer's oversight — it's that fifteen years of tutorials, Stack Overflow answers, and framework wrappers have trained developers to instantiate markdown parsers without passing any safety parameters. The pattern is so deeply embedded in the ecosystem that when HortusFox wrote `new Parsedown()` without `setSafeMode(true)`, they were reproducing a pattern that the broader PHP community had validated through thousands of identical implementations. The 'authenticated workspace member' constraint in this vulnerability's exploitation chain is the most dangerous framing error in the assessment. When only workspace members can inject the malicious content, the CVSS base score drops to 5.4 — but this scoring reflects a 2010 threat model that no longer applies. An attacker exploiting a colleague's session in a shared workspace has already bypassed the reconnaissance phase that anonymous XSS requires. They already know the victim's permissions, organizational context, and access patterns. This isn't lateral movement in the traditional sense — it's insider threat execution. The victim pool isn't degraded; it's pre-authenticated against the real target infrastructure. The fix isn't simply adding `setSafeMode(true)` to the plant notes endpoint. A proper remediation audits every Parsedown instantiation across the codebase — if one endpoint was written without safe mode, others likely are too. More fundamentally, this vulnerability class will keep appearing until the ecosystem treats opt-in safety as a design anti-pattern rather than a documentation problem. Parsedown's safe mode is documented; the failure is that developers must actively reason about HTML sanitization under time pressure when the secure path should require no additional thought. The deprecated threat modeling angle deserves attention beyond this CVE: the 'authenticated users only' assumption likely made sense when the product was small and every user was hand-vetted. That assumption calcified into code, the product grew around it, and nobody re-examined the rendering layer because nothing broke. Audit your own codebases for the same pattern — assumptions that made sense at launch but weren't re-validated as the application evolved.

Reviewed through automated stages and approved by a human before publication.