Quick answer
Direct answer
Risk scores
| CVSS metric | What it means |
|---|---|
| Attack vector (AV:N) | Network: reachable remotely |
| Attack complexity (AC:L) | Low complexity |
| Attack requirements (AT:N) | No attack requirements |
| Privileges required (PR:N) | No privileges required |
| User interaction (UI:N) | No user interaction |
| Confidentiality (VC:H) | High confidentiality impact |
| Integrity (VI:H) | High integrity impact |
| Availability (VA:N) | No availability impact |
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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
About Xiaomi Fileexplorer
CVE-2026-29515 affects Xiaomi Fileexplorer, a product from Xiaomi. Before acting, confirm where Xiaomi Fileexplorer runs in your estate, who owns it and whether it is reachable from the internet, because exposure decides real risk more than the score alone.
What the flaw is
In plain terms: MiCode FileExplorer contains an authentication bypass vulnerability in the embedded SwiFTP FTP server component that allows network attackers to log in without valid credentials. Attackers can send arbitrary username and password combinations to the PASS command handler, which unconditionally grants access and allows listing, reading, writing, and deleting files exposed by the FTP server. The MiCode/Explorer open source project has reached end-of-life status.
The weakness class is Missing Authorization. The software does not check permissions before an action.
Based on its CVSS vector, the flaw can be reached over the network, needs no login, and needs no user interaction. Apply the vendor fix and confirm exposure on internet facing and business critical assets first.
Affected versions and timeline
| Field | Detail |
|---|---|
| Product | Xiaomi Fileexplorer |
| Affected versions | Fileexplorer all listed versions |
| Published | Mar 11, 2026 |
| Last modified | Jul 14, 2026 |
| Added to CISA KEV | Not listed |
| Assigning CNA | disclosure@vulncheck.com |
How to detect it
- Inventory every instance of Xiaomi Fileexplorer and record the running version against the affected range above.
- Check external attack surface scans for internet facing instances of the component.
- Review logs on affected systems for unusual requests, errors or new processes around the vulnerable function.
- Confirm with an authenticated vulnerability scan once your scanner has a check for this CVE.
How to fix it
- Apply the fixed version of Xiaomi Fileexplorer named in the vendor advisory.
- If patching must wait, restrict network access to the affected service and put it behind authentication or a web application firewall rule.
- Rescan after the change to prove the exposure is gone, then close the ticket.
CTEM action plan
| CTEM stage | What to do for this CVE |
|---|---|
| Scope | Add every business service that depends on Xiaomi Fileexplorer to the current CTEM cycle. |
| Discover | Find all instances, including shadow and cloud deployments, and record versions and exposure. |
| Prioritize | Rank using EPSS and CVSS together with asset exposure and business impact. |
| Validate | Confirm the flaw is reachable and exploitable in your environment and that compensating controls work. |
| Mobilize | Assign the fix to the asset owner with a due date matched to the priority, then verify closure. |
CWE References
- CWE-303 More CVEs with this weakness
- CWE-862: Missing Authorization More CVEs with this weakness
Technical References
Frequently asked questions
Related CVEs
UDS Identity Config builds the Keycloak configuration image (realm, plugins, theme, truststore, JARs) consumed by UDS Core's Identity deployment. In versions 0.11.0 through 0.26.0, a logic error in the `client-kubernetes-secret` Keycloak client authenticator (shipped by `uds-identity-config` and consumed by UDS Core) causes the submitted `client_secret` to be overwritten with the mounted Kubernetes secret before comparison. An attacker who can reach the Keycloak token endpoint and knows a `client_id` using this authenticator can authenticate as that client with any `client_secret` value and obtain OAuth2 tokens scoped to the client's service account. In the case of the `uds-operator` client this token can be used to registry/modify other clients. Version 0.26.1 patches the issue.
OpenClaw versions prior to 2026.2.1 with the voice-call extension installed and enabled contain an authentication bypass vulnerability in inbound allowlist policy validation that accepts empty caller IDs and uses suffix-based matching instead of strict equality. Remote attackers can bypass inbound access controls by placing calls with missing caller IDs or numbers ending with allowlisted digits to reach the voice-call agent and execute tools.
The JwtAccessTokenValidator class in Apache CXF fails to validate the 'aud' (Audience) claims of incoming JWT access tokens. This allows a JWT issued for one Resource Server to be successfully replayed against a completely different Resource Server, leading to Token Confusion/Routing attacks. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue.
CoreDNS is a DNS server that chains plugins. In versions prior to 1.14.3, the tsig plugin can be bypassed on non-plain-DNS transports (DoT, DoH, DoH3, DoQ, and gRPC) because it trusts the transport writer's TsigStatus() instead of performing verification itself. The DoH and DoH3 writer's TsigStatus() always returns nil, the DoT server does not set TsigSecret on the dns.Server, and the DoQ and gRPC writers also unconditionally return nil. This allows an unauthenticated remote client to bypass TSIG-based authentication and access resources intended to be restricted behind a tsig require all policy. Plain DNS over TCP and UDP are not affected. This issue has been fixed in version 1.14.3.
In Eclipse Jetty, the Digest authentication server-side component uses ISO-8859-1 to encode the password as bytes. This was done because the initial specification for HTTP did not specify explicitly a charset, and it was assumed to be ISO-8859-1 for historical reasons. If the password contains characters that cannot be represented in ISO-8859-1, they are silently replaced by `?`. This happens with passwords that contain Chinese, Cyrillic or Greek characters, for example: `αβ123` converts to `??123`. An attacker can send a request with a digest `Authorization` header crafted with a password made of only `?` characters; the server would match any password of the same length that contains non-ISO-8859-1 characters. Recent HTTP Digest [RFC-7616](https://datatracker.ietf.org/doc/html/rfc7616) supports a `charset` parameters that defaults to UTF-8 that allows for correct encoding/decoding of passwords.
Description NGINX Ingress Controller has a vulnerability when implementing an externalAuth policy for ingress. NGINX Ingress Controller may mishandle the HTTP response from an OAuth IdP and allow an attacker to acquire unauthenticated access to protected paths before the proper external authentication can happen. Impact This vulnerability may allow remote attackers unauthenticated access to protected paths. There is no control plane exposure; this is a data plane issue only. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
Earn your free CTEM certification.
Learn to scope, prioritize, validate and mobilize fixes for CVEs like CVE-2026-29515 with a free CTEM certification.
Beginner / Practitioner / Program Leader
Explore certifications