CVE-2024-7314

What it actually does

CVE-2024-7314 is a critical authentication bypass in anji-plus AJ-Report. A remote unauthenticated attacker can append the path-parameter string ";swagger-ui" to HTTP requests and cause protected functionality to be treated as unauthenticated or allowed. Once the bypass is successful, the attacker can reach administrative or code-execution-capable AJ-Report functionality and execute arbitrary Java on the server. Because exploitation is network-accessible, low-complexity, requires no credentials, and can lead to code execution, the impact includes full compromise of confidentiality, integrity, and availability of the affected AJ-Report server and potentially the underlying host.

Why it matters to the business

Successful exploitation can allow an external attacker to take control of a reporting server, steal report data and connected data-source credentials, modify reports or business data outputs, disrupt reporting services, and use the server as a foothold into adjacent systems. The vulnerability has a CVSS score of 9.8, a high EPSS probability of exploitation, and weaponized exploit maturity, so internet-exposed AJ-Report deployments should be treated as high-priority even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies an exposed AJ-Report instance, commonly by probing web paths, titles, API responses, or Swagger-related endpoints. The attacker then sends crafted HTTP requests to protected AJ-Report routes with ";swagger-ui" appended to the request path or URL segment. If vulnerable routing or authentication filtering logic is present, the request bypasses normal authentication checks and reaches functionality that should require a logged-in administrator. From there, the attacker abuses accessible AJ-Report features or APIs that permit dynamic Java execution or server-side expression/script execution. The attacker can then run commands or Java payloads in the context of the application server, deploy persistence such as web shells or modified application artifacts, access report configurations and database connection secrets, and pivot to other internal services reachable from the compromised host.

How to fix it

Upgrade AJ-Report to a version that explicitly fixes CVE-2024-7314 when available from the vendor or project maintainers. If no fixed version is available for the deployed branch, remove public exposure immediately and place AJ-Report behind a trusted access control layer such as VPN, zero-trust access proxy, or mutually authenticated reverse proxy. Block requests containing path parameters such as ";swagger-ui" at the edge using a WAF, reverse proxy, or ingress controller, while treating this only as a temporary mitigation. Disable Swagger UI and unauthenticated API documentation in production if not required. Restrict administrative and report-management endpoints to trusted networks. Review and harden any AJ-Report features that allow script, expression, template, plugin, or Java execution. Rotate credentials stored in or accessible to AJ-Report after patching if exploitation is suspected. Rebuild from a known-good image if arbitrary code execution may have occurred.

How to confirm the fix worked

Confirm the running AJ-Report version against vendor-fixed release notes or commits for CVE-2024-7314. From an unauthenticated session, test representative protected endpoints with and without the ";swagger-ui" path parameter and verify that both requests are denied unless valid authentication is present. Validate that edge controls reject or log requests containing ";swagger-ui" in the URI. Confirm Swagger UI is not exposed to untrusted networks unless intentionally required and access-controlled. Review application configuration to ensure administrative endpoints are protected by authentication and authorization checks. After remediation, run web application scans or targeted regression tests to ensure path-parameter variations do not bypass authentication.

Typical attack path

1. Scan for internet-accessible anji-plus AJ-Report services.
2. Fingerprint the application using login pages, Swagger UI artifacts, API responses, or static resource paths.
3. Send crafted unauthenticated requests with ";swagger-ui" appended to protected URLs.
4. Confirm that protected API or administrative functionality is reachable without valid credentials.
5. Invoke vulnerable AJ-Report functionality capable of executing Java or server-side logic.
6. Execute payloads to enumerate the host, read configuration files, dump secrets, or run operating-system commands through Java runtime capabilities.
7. Establish persistence by uploading or modifying files, deploying a web shell, adding scheduled tasks, or altering application startup behavior.
8. Use stolen credentials or network access from the server to access databases, internal APIs, or additional infrastructure.

How to detect it

Review HTTP access logs, reverse-proxy logs, WAF logs, load balancer logs, and application logs for requests containing ";swagger-ui", particularly when sent to non-documentation, administrative, API, report, dataset, datasource, or management paths. Focus on unauthenticated source IPs receiving successful responses such as HTTP 200, 201, 204, 302, or large response bodies after such requests. Correlate suspicious requests with application logs showing access to privileged APIs without a valid session, creation or modification of reports, data sources, datasets, templates, plugins, scripts, or scheduled jobs. On the host, examine process creation telemetry for Java spawning shell interpreters or command-line tools, including sh, bash, cmd.exe, powershell.exe, curl, wget, nc, ncat, python, perl, or chmod. Review filesystem activity for newly created JSP/class/JAR files, modified application artifacts, suspicious files under web roots or upload directories, and unexpected changes to AJ-Report configuration. Check outbound network telemetry for new connections from the AJ-Report server shortly after suspicious requests. If centralized authentication is used, compare web requests against session or identity logs to identify protected actions performed without a valid authenticated session.

• ;swagger-ui
• %3Bswagger-ui
• %253Bswagger-ui
• ;swagger-ui/
• GET *;swagger-ui*
• POST *;swagger-ui*
• java.lang.Runtime
• ProcessBuilder
• /bin/sh -c
• /bin/bash -c
• cmd.exe /c
• powershell.exe
• wget http
• curl http
• nc -e
• ncat -e
• /swagger-ui/
• swagger-ui.html

What your security team should do

• Immediately inventory AJ-Report deployments, prioritizing internet-facing instances.
• If exposed to the internet, restrict access before or during patching because exploitation is weaponized and requires no credentials.
• Upgrade to a vendor-confirmed fixed version as soon as one is available; if none is available, isolate the service and apply compensating controls.
• Deploy temporary WAF or reverse-proxy rules blocking requests containing ";swagger-ui" in protected endpoint paths.
• Search historical web access logs for ";swagger-ui" path-parameter requests, especially those returning HTTP 200, 302, or other successful responses.
• Investigate any suspicious post-bypass activity, including unexpected Java process behavior, shell execution, file writes in web/application directories, and outbound network connections from the AJ-Report server.
• Rotate database, API, and service credentials stored in AJ-Report if exploitation cannot be confidently ruled out.
• Disable or restrict Swagger UI and production API documentation exposure.
• Rebuild affected servers from trusted images if evidence of arbitrary code execution, web shell deployment, or persistence is found.