CVE-2021-41381

What it actually does

CVE-2021-41381 is an unauthenticated network-reachable directory traversal vulnerability in Payara Micro Community 5.2021.6 and earlier. By submitting crafted path sequences such as ../ or encoded traversal variants in HTTP requests, an attacker can cause the server to resolve paths outside the intended web or application directory and disclose files accessible to the Payara Micro process. The primary impact is confidentiality loss: source files, deployment artifacts, configuration files, credentials, tokens, certificates, logs, or operating-system files may be exposed if readable by the service account.

Why it matters to the business

Successful exploitation can expose sensitive application and server data without requiring a login, potentially leading to credential theft, disclosure of proprietary code or customer data, and follow-on compromise of dependent systems. The issue has a high CVSS score, a high EPSS score, and weaponized exploit maturity, so internet-facing Payara Micro Community deployments should be treated as high-priority even though the vulnerability is not listed in CISA KEV and is not currently flagged as ransomware-associated.

How an attack unfolds

An attacker first identifies a Payara Micro Community service, usually through exposed HTTP/S application endpoints, banners, error pages, or technology fingerprinting. They then send requests containing traversal payloads such as ../, ..%2f, %2e%2e%2f, or double-encoded equivalents in paths or file-serving routes. If the vulnerable path normalization logic fails to constrain access to the intended directory, the server reads and returns files from elsewhere on the filesystem under the permissions of the Payara Micro process. The attacker typically starts with low-noise probes for common files, then targets higher-value artifacts such as application configuration, secrets, private keys, deployment descriptors, logs, and environment-specific files. Any recovered credentials or tokens may then be used for lateral movement, administrative access, cloud access, database access, or source-code and data theft.

How to fix it

Upgrade Payara Micro Community to a version later than 5.2021.6 that contains the vendor fix. If no exact fixed version is available in internal tracking, obtain the current supported Payara Micro Community release directly from the vendor and verify that it postdates the vulnerable 5.2021.6 release. Do not rely solely on web application filtering as a permanent fix. As interim mitigations, remove internet exposure where possible, place the service behind authenticated reverse proxies or access controls, block traversal payloads at a WAF or gateway, run Payara Micro with the least-privileged operating-system account, restrict filesystem permissions so the service cannot read secrets or unrelated application data, rotate any credentials that may have been stored on the host, and review whether sensitive files are packaged inside deployed applications unnecessarily.

How to confirm the fix worked

Confirm all Payara Micro Community instances are running a non-vulnerable version newer than 5.2021.6. Validate by checking deployment manifests, container images, startup logs, package inventories, and the Payara Micro JAR version used at runtime. Perform controlled testing from an approved scanner or manual test host using traversal payloads against file-serving routes and confirm that attempts to access files outside the intended application directory return a safe error such as 400, 403, or 404 and do not disclose file contents. Also verify that URL-encoded, double-encoded, mixed slash, and Windows-style traversal variants are rejected. Re-run external attack-surface scans to ensure no vulnerable Payara Micro Community services remain exposed.

Typical attack path

1. Scan for internet-facing services running Payara Micro Community or Java application servers with Payara-identifiable responses.
2. Send benign traversal probes using ../ and URL-encoded variants to determine whether files outside the web root can be read.
3. Attempt to retrieve known operating-system or application files such as /etc/passwd, win.ini, WEB-INF/web.xml, configuration files, logs, or keystores.
4. Review disclosed files for credentials, API keys, database connection strings, private keys, session secrets, internal hostnames, and application source details.
5. Use recovered secrets to access databases, administrative consoles, cloud resources, source repositories, or other internal services.
6. Maintain access or expand compromise using the newly obtained credentials or operational intelligence.

How to detect it

Review web server, reverse proxy, WAF, load balancer, and Payara application access logs for requests containing traversal sequences or attempts to retrieve sensitive local files. Include raw URI, decoded URI, query string, user agent, response status, response size, source IP, and timestamp in analysis. Pay special attention to successful 200 responses or unusually large responses to requests containing ../, encoded dot-dot-slash sequences, backslash traversal, or requests for files such as /etc/passwd, win.ini, WEB-INF/web.xml, domain.xml, keystores, logs, or application configuration files. Correlate suspicious requests with subsequent authentication activity using credentials stored on the server, new administrative sessions, unusual database connections, cloud API usage, or outbound connections from the application host. If available, inspect EDR file-access telemetry for the Payara Java process reading files outside expected application directories immediately after suspicious HTTP requests. Threat intelligence does not identify a specific named actor for this CVE, but the high EPSS score and weaponized status justify retrospective hunting across the full log retention period.

• ../
• ..\\
• %2e%2e%2f
• %2e%2e/
• ..%2f
• %2e%2e%5c
• ..%5c
• %252e%252e%252f
• %252e%252e%255c
• %c0%ae%c0%ae%c0%af
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• /proc/self/cmdline
• /WEB-INF/web.xml
• WEB-INF/web.xml
• META-INF/MANIFEST.MF
• domain.xml
• payara-resources.xml
• glassfish-resources.xml
• keystore.jks
• cacerts.jks
• truststore.jks
• application.properties
• application.yml
• config.properties
• log4j.properties
• log4j2.xml
• win.ini
• boot.ini
• windows/win.ini

What your security team should do

• Prioritize inventory and remediation of all Payara Micro Community 5.2021.6 and earlier deployments, especially internet-facing systems.
• Upgrade to a supported Payara Micro Community release newer than 5.2021.6 and rebuild any container images or application bundles that embed the vulnerable runtime.
• Hunt historical HTTP access logs for traversal attempts and suspicious file retrievals, focusing on encoded traversal payloads and requests for sensitive files.
• Assume sensitive local files may have been exposed if exploitation evidence is found; rotate application secrets, database passwords, API tokens, keystores, and certificates accessible to the Payara process.
• Add WAF or reverse-proxy rules to block path traversal patterns while upgrades are being completed, including encoded and double-encoded variants.
• Reduce blast radius by enforcing least-privilege filesystem permissions for the Payara runtime and removing secrets from application directories where possible.
• Monitor for follow-on use of credentials that may have been stored in disclosed configuration files, including unusual database, cloud, or administrative logins.