CVE-2026-40174
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 · uneditedMasa CMS is a content management system forked from Mura CMS. In versions 7.5.2 and earlier, the cUsers.updateAddress function does not properly validate anti-CSRF tokens for user address management operations. An attacker can induce a logged-in administrator to submit a forged request that adds, modifies, or deletes user address records, including email addresses and phone numbers. This can be used to alter contact information, redirect organizational communications, and corrupt address data in the user directory. This issue has been fixed in versions 7.2.10, 7.3.15, 7.4.10, and 7.5.3. As a workaround, restrict access to the administrative backend, use browser isolation for administrative sessions, or deploy filtering rules to block forged requests to the affected endpoint
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 confidenceMasa CMS versions 7.5.2 and earlier contain a Cross-Site Request Forgery (CSRF) vulnerability in the cUsers.updateAddress function. The function fails to properly validate anti-CSRF tokens when processing user address management operations (add, modify, delete). An authenticated administrator can be tricked into unknowingly submitting forged requests that modify user address data including email addresses and phone numbers.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS 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
- Authentication
- X
- User interaction
- P
- Scope
- X
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
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 Masa CMS installation and versionLocate the Masa CMS installation directory and check for version indicators such as a version file, build manifest, or admin dashboard version display. Common locations include the root directory or a /core or /admin folder.Affected if The installed version is 7.5.2 or any earlier version (7.x series up to and including 7.5.2).
-
Verify the cUsers.updateAddress function existsSearch the codebase for the updateAddress function within cUsers-related files. Look in modules or handlers related to user management, typically in files named cUsers.cfc, UserService.cfc, or similar under the core or handlers directory.Affected if The updateAddress function exists and is exposed as an endpoint for address management operations (add, modify, delete).
-
Inspect anti-CSRF token validation in the functionExamine the source code of the updateAddress function to determine if it performs anti-CSRF token validation before processing address operations. Look for token verification logic using functions like validateToken(), checkCSRF(), or similar validation routines.Affected if The function lacks proper anti-CSRF token validation or the validation can be bypassed for address add, modify, and delete operations.
-
Confirm admin access to the affected endpointDetermine if the admin backend interface is accessible and whether the updateAddress function is reachable by authenticated administrators. Check admin routing configurations and endpoint accessibility.Affected if The admin backend is accessible and the updateAddress function can be invoked by an authenticated administrator without additional CSRF protection.
You are affected if Masa CMS version 7.5.2 or earlier is installed, the cUsers.updateAddress function is present, and that function lacks proper anti-CSRF token validation for address management operations.
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.
dbcve · scopedApply the vendor patches (7.2.10, 7.3.15, 7.4.10, or 7.5.3) to add proper CSRF token validation to the updateAddress function. As interim measures, restrict admin backend access, use browser isolation, or deploy WAF rules to block forged requests to the affected endpoint.
Masa CMS 7.5.3 (or the latest version in your current branch: 7.2.10, 7.3.15, or 7.4.10)
- Identify the currently installed Masa CMS version by checking the admin dashboard or configuration files
- Backup the entire Masa CMS installation including the database before proceeding with the upgrade
- Download Masa CMS version 7.5.3 (or the latest version in your current release branch: 7.2.10 for 7.2.x, 7.3.15 for 7.3.x, 7.4.10 for 7.4.x, 7.5.3 for 7.5.x) from the official Masa CMS repository or distribution channel
- Follow the standard Masa CMS upgrade procedure: stop the application server, replace core files with the new version, run any included database migration scripts, and restart the application server
- Verify the upgrade was successful by logging into the administrative backend and confirming the version number
- As an additional security measure, verify that CSRF protection is functioning by examining the cUsers.updateAddress form for anti-CSRF token inclusion
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation2.0 h
- Implementation6.0 h
- Testing4.0 h
- Review / QA3.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,192.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-40174 — 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-2026-40174 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