Yes. CISA added CVE-2025-2749 to its Known Exploited Vulnerabilities catalogue on 20 April 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Kentico Xperience contains a path traversal vulnerability that could allow an authenticated user’s Staging Sync Server to upload arbitrary data to path relative locations.
What being in KEV tells you about real-world exploitation
CISA’s Known Exploited Vulnerabilities catalogue is a strong operational signal, not a theoretical one. When a CVE appears there, the practical assumption should be that exploitation has already occurred or is credible enough to justify urgent action, even if your own telemetry is quiet. For exposed internet-facing systems, that means treating the issue as active until proven otherwise.
For a path traversal issue, the first question is whether the vulnerable product is reachable in your environment and whether the affected component is enabled. If the answer is yes, the fact pattern shifts from “patch eventually” to “assume exposure, then validate whether abuse has already occurred.” That is especially important where the vulnerable path can write or stage content in places that influence application behaviour.
Authoritative triage should start with the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog, then move to asset confirmation and containment. If you need a broader exploitation-response playbook for this class of issue, NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is the right starting point.
How path traversal becomes a practical compromise path
Path traversal is dangerous because it can break the application’s assumptions about where data may be written or read. In a product that supports authenticated workflows, that often means a lower-friction attacker path than a classic unauthenticated exploit, because the attacker may only need valid access to a routine function, not a front-door auth bypass. The result can still be material compromise if the write location or relative path is sufficient to influence files, configuration, or content handling.
The key practitioner question is not just “can the traversal happen?” but “what does successful traversal let the actor change?” Arbitrary data upload to path-relative locations can create integrity issues, enable content manipulation, or set up secondary attack steps such as poisoning trusted files and staging persistence. In some environments, that can also create a useful foothold for later privilege escalation or lateral movement.
Because the direct answer already states that the flaw affects authenticated staging sync behaviour, the operational focus should be on trust boundaries inside the application rather than on perimeter access alone. A weakness that lives inside an authenticated workflow often slips past teams that only monitor login success, so the real exposure is usually in file handling, application logs, and post-upload side effects.
What to do if you cannot patch immediately
If remediation must wait, the best temporary control is to narrow the blast radius of the vulnerable function as much as possible. Restrict who can use the staging sync server, reduce network reachability, and remove any unnecessary path-writing privileges from the account or service context that exercises the feature. Where possible, disable the component until the vendor fix is in place.
You should also verify whether the vulnerable workflow can touch sensitive application paths, shared directories, or any location that is later consumed by automation. If a staging function can influence production-adjacent files, the risk is broader than a single malformed request. That is the point where compensating controls become a containment measure, not just a convenience.
For this class of issue, Web Application Attacks Guide is a useful internal reference for understanding the mechanics of path traversal and adjacent web attack patterns. If your response process needs broader vulnerability prioritisation, Vulnerability Management Guide provides the triage discipline that should sit around KEV-listed issues.
Risk and Threat Considerations
The main risk is not just that data can be written outside the intended directory, but that an authenticated application path can be abused to alter trusted content or set up follow-on compromise. When a flaw is already in KEV, the exposure should be treated as active attack surface, and for internet-reachable systems the window for opportunistic exploitation can be short.
Failure mechanism: The application accepts a relative path or upload target that is not sufficiently constrained, allowing an authenticated user flow to reach files or directories that should be off limits.
Impact: Attackers may be able to place or alter data in locations that affect application integrity, enable persistence, or support deeper compromise if the written content is later executed, interpreted, or trusted by other components.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Path traversal exposure depends on exposed, misconfigured application paths. |
| Recommendation — Harden the vulnerable application and restrict writable paths to reduce exploitability. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | KEV-listed exploitation requires rapid remediation or compensating controls. |
| AC-6 — Least Privilege | Limiting the staging sync server reduces the impact of path traversal abuse. | |
| AU-2 — Event Logging | Investigating possible abuse depends on preserved application and filesystem logs. | |
| Recommendation — Prioritise remediation for the vulnerable Kentico instance and document exception handling. Remove unnecessary write privileges from the affected workflow and service context. Log staging sync actions and filesystem changes needed for compromise assessment. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | A KEV-listed flaw requires structured vulnerability handling and timely treatment. |
| Recommendation — Track the CVE, confirm exposure, and apply the vendor fix or mitigation promptly. | ||
Practitioner Guidance
What to verify: Confirm whether Kentico Xperience is exposed, whether the staging sync server feature is enabled, and whether any filesystem paths reachable through that workflow map to sensitive application, configuration, or shared storage locations.
Decision rule: If you cannot patch immediately, treat the issue as a containment problem first, and reduce access, exposure, and file-system reach before you spend time proving exploitation in your own environment.
Evidence to retain: Keep request logs, file-write audit trails, staging sync activity, and any filesystem change records that can show whether unexpected paths were touched before remediation.
Practitioner takeaway: KEV listing means you should assume credible exploitation pressure now, so the right question is not whether the bug is important, but whether the vulnerable path is still reachable and write-capable in your environment.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2025-2749 (Kentico Xperience Path Traversal)?
- Is CVE-2025-2747 (Kentico Xperience CMS Authentication Bypass Using an Alternate Path or Channel) being exploited in the wild?
- CVE-2025-2749 (Kentico Xperience Path Traversal)
- Is CVE-2025-34028 (Commvault Command Center Path Traversal) being exploited in the wild?