CVE-2026-66647

The vulnerability in Homlisti theme stems from a dangerous assumption: developers treating WordPress's subscriber role as an implicit security boundary for custom theme functionality that WordPress core never anticipated. The subscriber role is WordPress's lowest privilege tier, and that status creates a false sense of security — developers building AJAX handlers, REST endpoints, and template redirects frequently omit explicit `current_user_can()` checks, betting that the role itself provides protection. It doesn't. WordPress's role system guarantees what core functionality users can access, not what custom theme code can be manipulated to do. This isn't a sophisticated access control bypass — it's a gap between what the role system guarantees and what developers assume it guarantees. The practical impact: any user who can register on the site (and subscriber registration is open on most WordPress installations) can trigger server-side state changes that should require elevated privileges. The CVSS 6.5 rating likely understates actual risk because subscriber accounts require no administrative approval and are trivial for attackers to obtain. Three compounding factors make this more serious than the score suggests. First, the blast radius extends beyond this theme — WordPress's data pipeline assumes user identity is established upstream, so downstream plugins frequently process theme-generated data without re-validating capability. A subscriber manipulating listing drafts has introduced a forged write operation into a pipeline other plugins trust. Second, this is almost certainly not an isolated missing check. Premium WordPress themes ship plugin-level functionality under development timelines that don't accommodate security-mature review processes. If one AJAX handler lacks capability gating, others likely do too. Third, themes don't auto-update. The median time from vendor patch to production deployment runs meaningfully longer than plugin updates — each Homlisti instance requires manual intervention, compatibility testing, and a deploy cycle. Prioritize remediation by auditing every custom AJAX handler, REST callback, and template redirect in the theme for explicit capability checks. Don't accept a patch at face value — examine whether the vendor shipped a surgical one-line fix or audited the full codebase. If it's the former, treat the theme as having systemic validation gaps and budget for ongoing security review of future updates. The organizational priority should reflect the pattern, not the score.

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