Is CVE-2025-31125 (Vite Vitejs Improper Access Control) being exploited in the wild?

Yes. CISA added CVE-2025-31125 to its Known Exploited Vulnerabilities catalogue on 22 January 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Vite Vitejs contains an improper access control vulnerability that exposes content of non-allowed files using ?inline&import or ?raw?import.

How to interpret “exploited in the wild” for a KEV-listed CVE

For this question, the practical answer is that the vulnerability should be treated as actively abused, not merely theoretically dangerous. KEV listing is a strong operational signal that defenders should assume exposure matters now, even before a local scan confirms whether a specific instance is reachable or whether exploitation has already touched your environment.

For teams triaging internet-facing build tools and development infrastructure, the first step is to verify whether Vite is present anywhere in the software estate, including embedded dependencies, developer environments, CI runners and shared build hosts. If the vulnerable component is reachable in production or pre-production, treat it as a live security issue rather than a routine backlog item.

A useful way to think about this is as an access-control failure with disclosure impact. The flaw allows non-allowed files to be exposed through request patterns such as inline import or raw import handling, so the security question is not only “is the version affected?” but also “what sensitive files could an attacker or scanner reach if the endpoint is exposed?”

What exposure matters most before you patch

The main concern is unintended file disclosure from systems that expose Vite endpoints to untrusted users, external testers or public traffic. That can include source files, configuration material, environment-adjacent content and other build-time artefacts that should never be fetchable through a web request.

In practice, the highest-value question is not the abstract CVE title but the reachable path: whether the application exposes the vulnerable import behaviour, whether the build environment contains anything sensitive worth stealing, and whether the same deployment pattern is repeated across multiple apps or tenants. Where a shared build platform is involved, one flaw can affect many projects at once.

For readers who want a broader process for handling confirmed exploitation signals, Zero-Day and Exploited Vulnerabilities Guide is the most relevant internal starting point because it frames KEV triage, emergency mitigation and post-patch hunting in one workflow. If you also need to assess adjacent vulnerability handling and prioritisation, Vulnerability Management Guide covers the prioritisation and verification practices that belong around a KEV event.

What to do if you cannot patch immediately

If patching must wait, focus on reducing reachability and narrowing the chance of file disclosure. That usually means restricting access to the vulnerable service, removing unnecessary public exposure, tightening reverse-proxy rules, and disabling or isolating any route or deployment pattern that makes the inline or raw import behaviour accessible to untrusted clients.

At the same time, review what the exposed file set could reveal if the flaw is exercised. If the service has already been exposed publicly, assume that reconnaissance may have happened and look for requests that use the affected import patterns, unusual asset fetches, or repeated probing of build and source paths.

From a control perspective, the key judgement is that mitigation is about reducing blast radius, not just waiting for a maintenance window. If the affected system supports development workflows, temporary containment may need to include access restriction, environment separation, and a short-term ban on hosting sensitive artefacts alongside the vulnerable component.

Risk and Threat Considerations

When a vulnerability is already in KEV, the main risk is that defenders are responding after exploitation interest has become real. That raises the likelihood of opportunistic scanning, mass exploitation and repeated probing against exposed Vite services, especially where build infrastructure is reachable from the internet or from loosely controlled internal networks.

Failure mechanism: An attacker or scanner uses the improper access control path to retrieve files that were intended to stay outside normal access, then uses the disclosed content to deepen reconnaissance, steal source material or identify follow-on targets in the build chain.

Impact: Even when the flaw does not directly yield code execution, content disclosure can expose secrets, internal paths, implementation details and deployment assumptions that make later compromise easier and harder to detect.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires rapid identification and prioritization of exposed vulnerable assets.
Recommendation — Prioritize and remediate exposed Vite instances using continuous vulnerability management.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Active exploitation makes timely flaw remediation central to reducing exposure from the improper access control issue.
	RA-5 — Vulnerability Monitoring and Scanning	Confirming exposure and hunting for affected deployments depends on ongoing vulnerability scanning and monitoring.
Recommendation — Accelerate remediation and verify vulnerable Vite deployments are updated or isolated. Scan for affected Vite deployments and monitor for exposed instances.
OWASP ASVS	V8 — Authorization	The flaw is an access-control failure that exposes files outside intended authorization boundaries.
	V15 — Secure Coding and Architecture	The issue reflects an architectural weakness in how request parameters can reach protected file content.
Recommendation — Review server-side authorization checks around file access and import handling. Remove unsafe request-to-file mappings and enforce safe file access paths.

Practitioner Guidance

What to verify: Confirm where Vite is deployed, whether the affected import behaviour is reachable from any untrusted network, and whether the service can return sensitive files from the hosting context. If the component only exists in developer workstations or isolated build paths, the urgency is different from a public-facing deployment.

What to prioritise: Prioritise containment and exposure reduction before deeper forensic work when the service is public or semi-public. If there is evidence of probing, treat the case as both a vulnerability-response and a compromise-assessment problem, not just a patching task.

Practitioner takeaway: For a KEV-listed flaw, the correct operational posture is to assume exploitation pressure is already present and to validate reachability, disclosure impact and compromise evidence in that order.