WhitepageWordPress extension · Myback.link
CVE-2023-45109
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedCross-Site Request Forgery (CSRF) vulnerability in ZAKSTAN WhitePage plugin <= 1.1.5 versions.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceCross-Site Request Forgery (CSRF) vulnerability in ZAKSTAN WhitePage plugin versions 1.1.5 and earlier allows attackers to trick authenticated users into performing unintended actions by leveraging the lack of proper CSRF token validation on sensitive operations.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
WhitepageWordPress extension
<= 1.1.5CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify WhitePage plugin versionLocate the plugin version metadata in the plugin configuration file, admin panel, or version manifest typically found in the plugin directory under version.ini, plugin.xml, or within the admin interface under 'Plugin Information' or 'About' sectionAffected if Installed version is 1.1.5 or earlier per the affected versions range (<= 1.1.5)
-
Verify sensitive operation endpointsReview the plugin's routing configuration or admin menu to identify state-changing actions such as user data modifications, settings changes, content updates, or authentication-related operationsAffected if The plugin handles user submissions, configuration changes, or authenticated actions without requiring explicit user confirmation
-
Inspect CSRF token presence in formsAccess the plugin's web forms for sensitive operations (e.g., admin settings, user management) and view the page source or intercept the HTTP response to check for hidden CSRF token fields or anti-CSRF tokens in the request headersAffected if Forms for sensitive operations lack hidden CSRF token fields or the requests do not include anti-CSRF tokens in headers
-
Check SameSite cookie attributesLog into the application and use browser developer tools (Application tab > Cookies) or intercept HTTP responses to inspect the session cookies set by the WhitePage pluginAffected if Session cookies are missing the SameSite attribute or have it set to 'None' without Secure flag, indicating improper CSRF cookie protection
-
Verify Origin/Referer header validationCapture an HTTP request to a sensitive endpoint using a proxy (e.g., Burp Suite, OWASP ZAP) and observe if the server validates the Origin or Referer headers before processing state-changing requestsAffected if The server accepts requests with missing or mismatched Origin/Referer headers for sensitive operations
The environment is affected if the installed WhitePage plugin version is 1.1.5 or earlier and sensitive operations lack CSRF token validation, proper SameSite cookie attributes, or Origin/Referer header checks.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
From vendor dataUpgrade to WhitePage plugin version 1.1.6 or later which should include anti-CSRF token implementation; alternatively, implement SameSite cookie attributes and verify Origin/Referer headers on state-changing requests.
Fix this in Whitepage
Scoped from the published advisory
- Consultation4.0 h
- Implementation8.0 h
- Testing6.0 h
- Review / QA4.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $6,176.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2023-45109 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2023-45109 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data