Themify Builder CVE-2026-75027: a public nonce did not authorise the target post
An anonymous visitor could alter styling data for arbitrary posts, including drafts and private content. Analysis of nonces, object authorisation and version 7.8.1.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 22 August 2026
- READING TIME
- 17 min read
- TOPIC
- Vulnerabilities and CVEs
CVE-2026-75027 was published on 22 August for Themify Builder, a visual page-building plug-in for WordPress. Releases through 7.8.0 did not authorise a style-data write correctly. An anonymous visitor could supply a chosen post identifier and JSON data, then alter stored padding and margin values for an arbitrary post, including a private item or draft.
The handler required a nonce, but wp_localize_script placed that token on frontend pages rendered by Builder. Any visitor could therefore obtain the value the application treated as its only control. The CVSS 3.1 score is 5.3: no account or user interaction is required, while the directly confirmed impact is limited integrity loss.
Scope and the 7.8.1 fix
The CNA record covers every release through 7.8.0. Themify’s official changelog lists 7.8.1, dated 19 August, as fixing “Missing authorization to unauthenticated arbitrary Builder data modification”. The patch was therefore available before formal CVE publication. That sequencing is a normal result of coordinated disclosure, not a contradiction.
Administrators should deploy 7.8.1 or later. Check every way Builder reaches the site: the standalone plug-in, a theme bundle, a staging image and manually copied extensions. The number in the WordPress directory does not always describe code embedded in an active theme or retained in cache.
The confirmed scope is a write to style data—padding and margin—for the selected post. Do not automatically infer disclosure of private content, PHP execution or Administrator takeover. Modification of metadata for a private object still proves the backend failed to enforce authority over that object.
A nonce protects intent, not permission
A WordPress nonce is primarily a CSRF control. It makes it harder for an external site to submit a request through a victim’s session, but it is not a long-term secret, authentication mechanism or RBAC decision. WordPress explicitly recommends combining nonce verification with current_user_can().
Rendering a token to anonymous visitors may still help reject accidental requests or associate a form with a flow. It cannot prove the holder may edit a post. In CVE-2026-75027, the same population that should have been denied could obtain the only required token.
A nonce can also be shared across objects and actions. Even a token legitimately acquired for one element must not authorise arbitrary post_id values. Object-level authorisation must run after resolving the identifier and check a capability for that particular post.
A correct server-side decision
A safe handler identifies the actor and requested action first. It then verifies the nonce, loads the target post, confirms it exists, checks the user’s permission to edit that object and validates an allowlisted JSON schema. Every decision must finish before writing metadata, generated CSS or cache.
Public visibility is not an authorisation rule. Permission to view a page does not grant permission to change its styling. Drafts and private posts warrant extra caution, but a public campaign landing page is also a high-value business asset.
JSON validation should enforce schema, types, numeric ranges, CSS units and a size limit. That is a separate layer. Even an administrator should not be able to store arbitrary structures or file paths through a margin field. The current record confirms limited style properties, so there is no evidence to label this CSS injection.
Practical impact
Changing padding or margin can break layout, hide a button, move a form, overlap components or reduce accessibility. It does not automatically inject script. For a store, campaign page or customer portal, limited visual manipulation can nevertheless damage conversion, trust and usability.
Support for private and draft IDs expands the integrity scope without proving content disclosure. Sequential identifiers may let an attacker submit changes for objects they cannot view. Incident responders should therefore inspect more than recently published pages.
Where Builder creates CSS files, the effect may persist through application cache and a CDN. After upgrading or restoring metadata, invalidate generated artifacts, purge cache and compare the rendered result. Database state and the page users see may temporarily differ.
Upgrade and safe regression testing
Back up the database and wp-content, move to at least 7.8.1 and test the editor in staging. Verify authorised style saves, preview, CSS generation, private pages, multisite and theme integration. Clear stale application, CDN and opcode cache after rollout.
A regression test should prove three cases: an anonymous request is denied, a logged-in user without authority over a particular post cannot modify it, and an authorised editor may save only allowed fields. Use a test post and a harmless value; do not experiment on someone else’s content or production drafts.
If immediate upgrading is impossible, disable the endpoint or Builder, restrict the route at a reverse proxy and monitor metadata changes. Removing the nonce from frontend output may reduce ease of abuse but does not implement authorisation and is not a complete fix.
Hunting and effect remediation
Review access logs for style-save handler requests without an authenticated session, with unusual post_id values, at high frequency or from sources unrelated to administrators. Correlate timing with postmeta, generated stylesheets and cache changes. Preserve raw logs, while redacting cookies and nonces in working copies.
Compare Builder data with backups, revision history and the declared design. WordPress revisions may omit plug-in metadata, so a database backup or audit trail is more valuable than the editor screen alone. Include public, private and draft objects.
When an unauthorised modification is found, restore only confirmed fields, rebuild CSS and clear cache. Rotating every password does not follow automatically from this CVE because the record does not describe credential theft. Expand response only if logs show additional activity.
CNA facts and Breachroad conclusions
Publication date, scope through 7.8.0, anonymous access, the public nonce, attacker-chosen post_id, style JSON and CVSS 5.3 come from Wordfence’s CNA record. Version 7.8.1 and its fix date come from the official Themify changelog. No active exploitation is reported.
The object-level authorisation model, cache procedure, role testing and hunting guidance are Breachroad conclusions. Application security and cybersecurity training helps developers distinguish a nonce, identity and permission, while web application penetration testing validates those boundaries in real workflows.
