# Edition-Agnostic Protection and Edition-Aware Alerting Fail Independently ## Claim Blocking an attack and knowing you were vulnerable are separate capabilities with separate data dependencies, so a defence stack can keep protecting correctly while its reporting layer goes completely blind. <!-- atomicity: 1 idea ✓ --> ## Evidence **Source**: [[3. Resources/Readwise/Articles/One slug, seven editions the miniOrange SAML SSO bug that let anyone log in as your WordPress admin|One slug, seven editions]] The setup is a versioning collision: > [!quote] > miniOrange ships this plugin under one slug, miniorange-saml-20-single-sign-on, which includes seven independently versioned product editions. And the consequence for anything that reasons about version numbers: > [!quote] > every paid install carries a higher version number than 5.4.5, so every paid install reads as already patched The protection layer was unaffected — a rule that blocks the exploit pattern does not care which edition is installed, because it matches on behaviour. The *alerting* layer failed completely, because it matches on version, and the version was meaningless across editions sharing a slug. The general shape: defences that work on observed behaviour and defences that work on declared identity have different failure modes, and a shared slug breaks only the second. A site could be simultaneously protected and reported as not-at-risk, which is the worst combination for anyone trying to prioritise remediation. ## Scope & conditions - Requires a namespace where one identifier maps to multiple independently-versioned artifacts. Common in WordPress freemium plugins; also appears in vendored dependencies and repackaged distributions. - The generalisation holds beyond this case: **any control keyed on declared metadata inherits that metadata's integrity**, while behavioural controls do not. - Detection is the harder half to fix, because it cannot fall back to behaviour — a scanner has nothing to observe until an attack occurs. - Practical consequence for fleet operators: a clean vulnerability report across a plugin with edition-split versioning is not evidence of anything. ## Links - [[WordPress Hosting Security Stack MOC]] — why a clean vulnerability report means nothing when one slug carries seven versioned editions - [[3. Resources/Permanent Notes/Filesystem Checks Beat Declared Flags for Classification Stability]] — the same lesson: observed state outlives declared state - [[3. Resources/Permanent Notes/Post-Login Visibility Is a Distinct Security Layer From Authentication Hardening]] — another case of protection and visibility being separable layers - [[3. Resources/Permanent Notes/A Vulnerabilitys Classification Follows the Threat Model Not the Reports Novelty]] — extends: what a report does and does not tell you - [[3. Resources/Permanent Notes/An Open Marketplace Turns Extensibility Into Liability Without an Owned Security Layer]] — the ecosystem condition that makes slug-level ambiguity possible