CVE-2021-3199: ONLYOFFICE Path Traversal and RCE
Active exploitation confirmed in CISA KEV.
Active exploitation confirmed in the wild. CISA added this to the KEV catalog on 2026-10-08. Federal agencies must patch by 2026-10-11.
TL;DR - CVE-2021-3199 is a critical path-traversal vulnerability in ONLYOFFICE Document Server versions before 5.6.3 when JWT is used. - Public proof-of-concept code exists, and CISA lists the vulnerability in its Known Exploited Vulnerabilities catalog. - Upgrade to ONLYOFFICE Document Server 5.6.3 or later and investigate exposed systems for suspicious
/uploadactivity.
What Is CVE-2021-3199?
CVE-2021-3199 is a critical path-traversal vulnerability in the /upload functionality of ONLYOFFICE Document Server, also identified by CISA as ONLYOFFICE Docs Server. The issue affects versions before 5.6.3 when JWT is used.
An attacker can manipulate an image-upload parameter with a /.. sequence. This may allow files to be written outside the intended upload directory and potentially lead to remote code execution.
The vulnerability was published on January 26, 2021. NVD assigns it a CVSS v3.1 base score of 9.8, or Critical. CISA added CVE-2021-3199 to its Known Exploited Vulnerabilities catalog on October 8, 2026, with a remediation deadline of October 11, 2026.
CISA KEV inclusion means defenders should treat exploitation as confirmed in the wild rather than as a theoretical risk. Organizations reviewing this issue should also understand broader supply-chain attack terminology when assessing risks across document-processing and collaboration platforms.
| Field | Assessment |
|---|---|
| CVE ID | CVE-2021-3199 |
| Product | ONLYOFFICE Document Server / ONLYOFFICE Docs |
| CVSS | 9.8 Critical |
| Attack vector | Network |
| Authentication | No authentication required in the CVSS assessment; the vulnerable scenario is documented when JWT is used |
| Privileges required | None in the CVSS assessment |
| User interaction | None in the CVSS assessment |
| Affected versions | Versions before 5.6.3 |
| Fixed version | 5.6.3 |
| Patch available | Yes |
| CISA KEV | Yes, added 2026-10-08 |
| Public PoC | Yes |
| Confirmed exploitation | Yes, based on CISA KEV inclusion |
| Ransomware campaign use | Unknown |
The exact CVSS vector string was not included in the supplied NVD API response. The score is consistent with a network-reachable, low-complexity issue requiring no privileges or user interaction, with impacts to confidentiality, integrity, and availability. Confirm the vector directly in the NVD record before using it in a formal compliance report.
Analyst’s Take: Treat an exposed, pre-5.6.3 deployment as an incident-review priority, not only a patching task. CISA KEV inclusion and public PoC code support immediate remediation, while the available research does not establish a complete exploit chain or a configuration workaround that removes the risk.
What Is the Root Cause?
The apparent root cause is inadequate validation and normalization of user-controlled path data in the image-upload workflow. The vulnerable endpoint accepts upload-related parameters, and an attacker can include a traversal sequence such as /.. to influence where the server writes the resulting file.
A secure upload handler should canonicalize every resolved path and verify that it remains inside a dedicated upload directory. In this case, the available technical material indicates that the application could resolve attacker-controlled path data outside that directory.
The impact is therefore more serious than simple file disclosure. The upload primitive may provide arbitrary file-write capability, which can become remote code execution when an attacker can place content in a location interpreted by the application or an underlying service.
The documented vulnerability description states that remote code execution can occur through /upload in affected versions when JWT is used. The available sources do not establish the exact vulnerable source-code function, the complete exploit chain, or the precise patch diff. Do not assume that disabling one visible upload route fully mitigates the issue unless that workaround is confirmed by ONLYOFFICE documentation.
Technical Root-Cause Summary
The failed security boundary was the one between an application-controlled upload location and attacker-controlled path data.
A secure implementation should:
- Treat upload paths as untrusted input.
- Canonicalize paths before use.
- Confirm that the resolved path remains inside the intended directory.
- Reject traversal sequences and equivalent encoded representations.
- Store uploaded content outside executable or web-accessible directories.
- Apply least-privilege filesystem permissions.
- Monitor file creation and process execution by the service account.
Once an attacker can place content in a location interpreted by the application or an underlying service, arbitrary file write may become code execution. The practical severity depends on the service account, deployment layout, exposed endpoints, and write permissions.
Who Needs to Act?
Organizations running ONLYOFFICE Document Server, including deployments referred to as ONLYOFFICE Docs, should identify every instance below version 5.6.3.
The authoritative affected range in the supplied NVD material is all versions before 5.6.3. A secondary source describes a narrower range of 5.1.5 through 5.6.2, but that starting point was not present in the NVD API response. Until the vendor confirms otherwise, treat every version before 5.6.3 as potentially affected.
| Deployment condition | Required action |
|---|---|
| Document Server before 5.6.3 and JWT enabled | Treat as vulnerable and upgrade immediately |
| Internet-facing Document Server before 5.6.3 | Prioritize for emergency remediation and incident review |
| Internal-only Document Server before 5.6.3 | Upgrade promptly; assess exposure through integrations and reverse proxies |
| Document Server 5.6.3 or later | Verify the deployed build and continue monitoring |
| Version unknown | Determine the version before assuming the system is safe |
| Unable to patch | Restrict exposure and evaluate discontinuing use if effective mitigation cannot be confirmed |
JWT usage is an important condition in the published vulnerability description. Organizations should not use uncertainty about JWT configuration as a reason to defer remediation. CISA KEV inclusion and public exploit code justify treating exposed, pre-5.6.3 installations as high-priority assets.
Inventory work should include:
- Standalone servers
- Docker and other container deployments
- Virtual appliances
- Cloud images
- Instances embedded in collaboration platforms
- Reverse-proxy backends
- Service-provider integrations
A Document Server that is not directly exposed to the internet may still be reachable through an application gateway, trusted integration, or misconfigured internal network.
Why Is the CVSS Score Critical?
NVD assigns CVE-2021-3199 a CVSS v3.1 base score of 9.8 Critical. The supplied NVD response did not provide the vector string, so the component interpretation below is based on the score and vulnerability description. Confirm the official vector in the NVD record before reproducing it in an audit, advisory, or risk register.
| Component | Practical meaning |
|---|---|
| Network attack vector | The vulnerable functionality is reachable over a network through the Document Server service |
| Low attack complexity | Exploitation does not appear to require unusual conditions beyond access to the vulnerable functionality |
| No privileges required | The CVSS assessment treats the attack as not requiring an existing privileged account |
| No user interaction | A victim does not need to open a document or approve an action for the server-side request to be processed |
| High confidentiality impact | Successful code execution can expose documents, credentials, tokens, and server data |
| High integrity impact | An attacker may write files or alter application and host content |
| High availability impact | Code execution or destructive file operations can disrupt the service or host |
CVSS measures technical severity, not the full operational risk. Risk is elevated because the vulnerability has public proof-of-concept references and is listed in CISA KEV.
Actual exploitability can vary with network controls, reverse-proxy rules, JWT deployment, container isolation, and service-account permissions. These factors should influence prioritization but should not override the need to patch.
Has CVE-2021-3199 Been Exploited?
Yes. CISA lists CVE-2021-3199 in the Known Exploited Vulnerabilities catalog.
The supplied record reports on_kev: true, with a date added of October 8, 2026, and a remediation deadline of October 11, 2026. This is the strongest available indication in the research material that exploitation has occurred in the wild.
Public proof-of-concept code also exists. Referenced repositories include:
poc_uploadImageFile.pyinmoehw/poc_exploits- A related copy in
nola-milkin/poc_exploits
These references show that exploit guidance or code is publicly available for the vulnerable upload functionality.
The available record does not confirm ransomware campaign use. CISA’s knownRansomwareCampaignUse value is Unknown. That status does not reduce the significance of confirmed exploitation.
Defenders should assume that internet-exposed, pre-5.6.3 systems may have been scanned or targeted, particularly if they were reachable before remediation. Patch validation should therefore be accompanied by retrospective investigation.
How Can I Tell Whether My System Was Exploited?
Start by identifying installed versions and deployment exposure. Check:
- Package metadata
- Container image tags
- Deployment manifests
- Application banners
- Vendor management interfaces
- Historical deployment records
Do not rely solely on a current banner if the system may have been upgraded or rebuilt after an incident.
Review reverse-proxy, web-server, and application logs for requests to /upload, especially requests containing traversal indicators or unusual image-upload parameters. A generic example for combined access logs is:
Technical Notes: Detection patterns
# Search common web and reverse-proxy logs for the affected endpoint
grep -RniE '/upload|%2f%2e%2e|%2e%2e|/\.\.|\\\.\.' \
/var/log/nginx /var/log/apache2 /var/log/onlyoffice 2>/dev/null
Potential indicators include:
- URL-encoded traversal sequences such as
%2e%2e - Double-encoded traversal attempts
- Literal
/..sequences - Repeated upload requests
- Unexpected file extensions
- Successful responses to malformed upload parameters
- Files created outside normal upload and temporary directories
- Child processes launched by the Document Server process
- Suspicious outbound connections after upload requests
These patterns are not proof of exploitation. Legitimate integrations may use /upload, and attackers may encode or obfuscate requests differently.
Search filesystem telemetry for files created outside normal upload and temporary directories shortly after suspicious requests. Useful data sources include:
- Linux audit logs
- Endpoint detection telemetry
- Container runtime events
- File-integrity monitoring
- Reverse-proxy logs
- Process execution telemetry
Pay particular attention to web-accessible directories, application code directories, startup locations, temporary directories, and files owned by the Document Server service account.
For an Elasticsearch-compatible log platform, a starting query could be:
url.path:"/upload" AND
(
url.query:*"%2e%2e"* OR
url.query:*"..%2f"* OR
url.query:*"%2f..%"* OR
url.query:"*../*"
)
Field names vary by schema. Adapt the query to the normalized URL and raw request fields available in your environment.
The absence of matching logs does not establish that the system was not compromised. Logs may have been rotated, requests may have passed through a proxy that discarded query strings, and endpoint telemetry may not cover containers.
If an affected exposed instance shows unexplained file creation, command execution, new accounts, altered configuration, or suspicious outbound traffic, preserve evidence and begin incident-response handling.
Bottom Line
CVE-2021-3199 is a critical, actively exploited ONLYOFFICE Document Server vulnerability. Identify every instance before version 5.6.3, prioritize internet-facing systems, and upgrade to 5.6.3 or later.
Pair remediation with threat hunting for suspicious /upload requests, traversal indicators, unauthorized file creation, unexpected processes, and outbound connections. If compromise is suspected, preserve evidence and follow incident-response procedures before rebuilding or rotating credentials.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
How Do I Remediate CVE-2021-3199?
Upgrade ONLYOFFICE Document Server to version 5.6.3 or later. Version 5.6.3 is the fixed version identified in the supplied vulnerability and changelog references.
Verify the final running version after the upgrade rather than relying only on the package manager’s intended state.
For a Docker deployment, use the organization’s approved image source and change the tag to a supported release at or above 5.6.3. A generic operational pattern is:
Technical Notes: Upgrade example
# Review the currently deployed image and compose configuration
docker compose images
docker compose config
# Update the image tag in the approved compose or deployment manifest,
# then pull and recreate the service
docker compose pull
docker compose up -d --force-recreate
# Verify the resulting container and image
docker compose ps
docker inspect <container_name> --format '{{.Config.Image}}'
The exact image name, tag, data volumes, secrets, and environment variables differ by deployment. Do not copy a production command without validating backup, rollback, and configuration requirements.
For package- or appliance-based installations, use ONLYOFFICE’s supported upgrade procedure and confirm that the installed build is 5.6.3 or later.
Temporary risk reduction
If immediate upgrading is impossible:
- Restrict access to trusted networks.
- Place the service behind an authenticated reverse proxy where compatible.
- Limit access to vulnerable upload functionality.
- Apply vendor-recommended mitigations.
- Monitor requests and filesystem activity.
- Schedule the upgrade as an emergency change.
These steps reduce risk but are not substitutes for the fixed release. The supplied research does not establish a vendor-confirmed configuration workaround that eliminates the vulnerability.
Where effective mitigation is unavailable, evaluate discontinuing use of the product. Isolate affected systems from the internet, preserve relevant logs and disk images, and assess whether a clean rebuild is more appropriate than an in-place upgrade if compromise indicators are found.
Post-remediation actions
After remediation:
- Rotate credentials and tokens if compromise is possible.
- Review JWT secrets.
- Rotate service credentials and API keys.
- Review administrator accounts.
- Check credentials accessible to the Document Server process.
- Remove unauthorized files and persistence mechanisms.
- Validate the upgraded version.
- Continue monitoring
/uploadactivity. - Confirm that reverse-proxy and firewall rules match the intended exposure.
If your organization uses a password manager for administrative credentials, review whether shared or exposed credentials should be rotated and centrally managed. A solution such as Try 1Password → may be relevant for teams formalizing privileged-credential controls, but it does not replace vulnerability remediation or incident response.
Sources and References
The primary technical description and affected-version information come from the NVD record for CVE-2021-3199. The CVE record and NVD entry describe directory traversal with potential remote code execution through /upload, involving an image-upload parameter and a /.. sequence in affected versions before 5.6.3 when JWT is used.
The fixed-version reference is associated with the ONLYOFFICE DocumentServer changelog entry for 5.6.3. Because the supplied research does not include the complete patch diff or a definitive vulnerable function, source-level conclusions should be limited to documented behavior rather than an unverified code path.
Relevant references: