CVE-2021-27670

What it actually does

The flaw is a server-side request forgery condition in Appspace 6.2.4 where the unauthenticated endpoint /api/v1/core/proxy/jsonprequest accepts a user-controlled url parameter and causes the server to fetch that URL. Because the request is made from the vulnerable server rather than the attacker’s machine, an attacker can potentially reach internal-only services, cloud metadata endpoints, loopback interfaces, administrative APIs, or other network locations that are not directly exposed to the internet. Depending on what the Appspace server can access, this can result in sensitive data disclosure, credential or token theft, interaction with internal services, and in some environments further compromise of downstream systems. The supplied CVSS vector indicates network reachability, low attack complexity, no authentication, and high confidentiality, integrity, and availability impact.

Why it matters to the business

A vulnerable internet-facing deployment can be abused as a bridge into internal networks, exposing data and services that were assumed to be private. This can lead to theft of cloud credentials, application secrets, internal configuration data, or service responses, and may support lateral movement or follow-on attacks. Although this issue is not listed in CISA KEV and is not marked as ransomware-associated, the EPSS score is high at 0.61274 and exploit maturity is marked weaponized, so security teams should treat exposed instances as high priority. The issue is old, published in 2021, which increases the likelihood that exploit techniques are widely known and that unpatched systems are easy to identify.

How an attack unfolds

An attacker first identifies an exposed Appspace 6.2.4 instance and tests whether /api/v1/core/proxy/jsonprequest can be reached without authentication. They then supply a crafted url parameter pointing to a target that the Appspace server can access, such as localhost, RFC1918 private IP ranges, cloud instance metadata services, or internal HTTP APIs. If the server fetches the attacker-supplied destination and returns the response, the attacker can enumerate internal hosts, retrieve metadata or configuration, and collect secrets exposed through internal endpoints. In cloud environments, the most damaging path is often requesting instance metadata endpoints to obtain temporary credentials or identity data. If credentials or privileged internal APIs are exposed, the attacker may use the SSRF as an initial foothold for broader compromise.

How to fix it

Upgrade Appspace to a vendor-supported version that fixes the SSRF behavior and retire Appspace 6.2.4 wherever present. If fixed package metadata is being used for operating system inventories, the supplied package data indicates chromium on Debian 11, Debian 12, and Debian 13 should be at least 80.0.3987.106-1, and chromium-browser on Ubuntu 16.04 LTS should be at least 80.0.3987.87-0ubuntu0.16.04.1; however, confirm product applicability because the vulnerability description specifically identifies Appspace 6.2.4. As compensating controls, restrict external access to the vulnerable endpoint, require authentication at the application or reverse-proxy layer, block requests from the application server to cloud metadata IPs and internal-only networks unless explicitly required, enforce egress filtering, deny non-HTTP/HTTPS schemes, and implement strict allowlists for any server-side URL fetch functionality. Disable or remove the proxy/jsonprequest capability if it is not required.

How to confirm the fix worked

Confirm the installed Appspace version is no longer 6.2.4 or otherwise verify the vendor patch level that remediates the vulnerable proxy behavior. From an untrusted network location, verify that /api/v1/core/proxy/jsonprequest is not reachable without authentication and cannot be used to fetch arbitrary external, loopback, private, link-local, or metadata URLs. Test that requests targeting 127.0.0.1, localhost, ::1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 169.254.169.254 are blocked or return a safe error. Review egress firewall logs to confirm the application server is not allowed to initiate unnecessary outbound connections to internal management networks or cloud metadata services. For package-based validation where applicable, verify Debian chromium is 80.0.3987.106-1 or later and Ubuntu 16.04 chromium-browser is 80.0.3987.87-0ubuntu0.16.04.1 or later.

Typical attack path

1. Discover an internet-facing Appspace 6.2.4 deployment or a system exposing the vulnerable proxy endpoint.
2. Send requests to /api/v1/core/proxy/jsonprequest with a controlled url parameter to confirm server-side fetching behavior.
3. Probe loopback and private address ranges from the server’s network perspective to identify reachable internal services.
4. Attempt access to cloud metadata endpoints, service discovery endpoints, internal APIs, or administrative interfaces.
5. Capture returned responses containing tokens, credentials, configuration, hostnames, or sensitive business data.
6. Use any recovered credentials or internal service access to escalate privileges, move laterally, or stage additional attacks.

How to detect it

Investigate whether the endpoint /api/v1/core/proxy/jsonprequest has been accessed with a url parameter pointing to localhost, loopback addresses, private IP ranges, link-local addresses, cloud metadata services, unusual ports, or nonstandard schemes. Review web server access logs, Appspace application logs, reverse-proxy logs, WAF events, load balancer logs, and network egress logs from Appspace servers. Look for successful 200 responses or unusually sized responses to requests that include internal destinations in the url parameter. Correlate suspicious requests with outbound connections from the Appspace server to 127.0.0.1, ::1, 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. In cloud environments, review metadata service access patterns and cloud audit logs for use of temporary credentials associated with the affected server shortly after suspicious SSRF requests. Also look for URL encoding, double encoding, decimal or hexadecimal IP representations, DNS names resolving to private IP space, redirects to metadata services, and requests using file, gopher, dict, ftp, or other unexpected schemes. Absence of these indicators does not prove non-exploitation, because attackers can use benign-looking hostnames, redirects, or infrastructure they control to trigger server-side access.

• /api/v1/core/proxy/jsonprequest
• api/v1/core/proxy/jsonprequest?url=
• url=http://127.0.0.1
• url=https://127.0.0.1
• url=http://localhost
• url=https://localhost
• url=http://[::1]
• url=http://0.0.0.0
• url=http://169.254.169.254
• url=http://169.254.169.254/latest/meta-data
• url=http://169.254.169.254/latest/user-data
• url=http://169.254.169.254/latest/dynamic/instance-identity
• url=http://metadata.google.internal
• url=http://metadata.google.internal/computeMetadata/v1
• url=http://169.254.169.254/metadata/instance
• url=http://100.100.100.200
• url=http://10.
• url=http://172.16.
• url=http://172.17.
• url=http://172.18.
• url=http://172.19.
• url=http://172.20.
• url=http://172.21.
• url=http://172.22.
• url=http://172.23.
• url=http://172.24.
• url=http://172.25.
• url=http://172.26.
• url=http://172.27.
• url=http://172.28.
• url=http://172.29.
• url=http://172.30.
• url=http://172.31.
• url=http://192.168.
• url=file://
• url=gopher://
• url=dict://
• url=ftp://
• %2fapi%2fv1%2fcore%2fproxy%2fjsonprequest
• 169.254.169.254/latest/meta-data
• metadata.google.internal/computeMetadata/v1
• X-aws-ec2-metadata-token
• Metadata-Flavor: Google

What your security team should do

• Immediately inventory externally reachable Appspace deployments and identify any running Appspace 6.2.4.
• Patch or upgrade vulnerable Appspace systems first when they are internet-facing, have cloud metadata access, or reside in networks with sensitive internal services.
• Place temporary access controls in front of /api/v1/core/proxy/jsonprequest while remediation is underway, including authentication, IP restrictions, or blocking rules.
• Add egress controls preventing Appspace servers from reaching cloud metadata endpoints, loopback-only services, and unnecessary private network ranges.
• Search historical web, reverse-proxy, WAF, and application logs for suspicious requests to /api/v1/core/proxy/jsonprequest containing url parameters that reference internal, loopback, link-local, or metadata addresses.
• Review cloud audit logs and identity-provider logs for unusual activity from roles or credentials assigned to affected servers.
• If evidence of metadata or credential exposure is found, rotate affected credentials, revoke tokens, and investigate downstream access.
• Tune SIEM and WAF detections for SSRF payloads targeting metadata services, localhost, private IP ranges, and alternative URL schemes.
• Confirm vulnerability scanner findings are product-correct, because the supplied affected package metadata references Chromium packages while the vulnerability description references Appspace.