Skip to main content

Peppermint EUVDEUVD-2026-70668

| CVE-2026-85391 CRITICAL
Use of Hard-coded Credentials (CWE-798)
2026-09-03 VulnCheck GHSA-mjr9-fw4p-963x
9.3
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Locate exposed Peppermint API
  2. Delivery
    Retrieve public hardcoded JWT secret
  3. Exploit
    Forge admin-user JWT with secret
  4. Execution
    Send request to protected endpoint
  5. Impact
    Gain full unauthenticated account access

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Credential externalization
MITRE ATT&CK

2 techniques across 2 tactics: Persistence, Credential Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires that the target Peppermint deployment (through 0.5.5) still uses the hardcoded JWT signing secret from the shipped docker-compose.yml - i.e., the operator did not override it with a custom environment value. Given that condition, exploitation is remote, unauthenticated, requires no user interaction, and works against default configurations: the attacker only needs network reachability to the API and the publicly known secret to forge tokens for any user ID. The primary limiting factor is deployment hardening - instances that set a unique random JWT secret are not exploitable.

Impact

This is a genuine high-priority issue for exposed instances. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, base 9.3) is consistent with the description: fully remote, no authentication, no user interaction, and complete compromise of confidentiality and integrity by forging admin tokens. No EPSS score, KEV entry, or public PoC is provided; the vulnerability is not listed in CISA KEV and there is no confirmation of active exploitation. The most important caveat is a configuration dependency the CVSS does not capture: exploitation only works if the operator left the docker-compose default secret in place. Deployments that override the JWT secret via environment variable are not affected, so real-world exposure hinges on operator hygiene rather than being universal. Weighing signals: the technical impact is severe and trivially automatable against default installs, but the affected product is niche and the vulnerable condition is avoidable, so treat internet-exposed default deployments as urgent and hardened/overridden ones as not affected.

Exploit ScenarioDerived

An attacker locates an internet-exposed Peppermint instance still using the default docker-compose configuration, retrieves the public JWT signing secret from the project's docker-compose.yml, and locally signs a JWT asserting an administrator user ID. They present this forged token to the API and gain full authenticated access to tickets, user data, and admin functions without ever knowing a password. No published exploit tool is needed - the secret itself is the exploit.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.
No patch listed yet 0.3% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 03, 2026

Unauthenticated session-token forgery in Peppermint (an open-source self-hosted helpdesk/ticketing platform) versions through 0.5.5 lets any remote attacker impersonate arbitrary users. The application's docker-compose.yml ships a hardcoded JWT signing secret that is public in the project repository, so an attacker who knows the secret can mint valid tokens for any user ID - including administrators - and reach protected API endpoints without credentials. Reported by VulnCheck; no public exploit identified at time of analysis, though the 'exploit' is trivially the published secret itself.

RemediationAI

No vendor-released fixed version is identified in the provided data at time of analysis, so the immediate action is a compensating control: override the JWT signing secret with a strong, randomly generated value unique to your deployment (set the JWT secret environment variable in docker-compose.yml / your orchestration to a high-entropy random string) and restart the API so the hardcoded default is never used - this invalidates any previously issued tokens, forcing all users to re-authenticate, which is the intended and acceptable side effect. Until that is confirmed, restrict network exposure of the Peppermint API to trusted networks/VPN rather than the public internet to limit who can present forged tokens. Track the fix via GitHub issue https://github.com/Peppermint-Lab/peppermint/issues/528 and the VulnCheck advisory (https://www.vulncheck.com/advisories/peppermint-through-0.5.5-use-of-hard-coded-jwt-signing-secret-in-docker-compose-yml), and rotate the secret again after upgrading to any patched release.

Affected VersionsENISA

Peppermint 0 ≤0.5.5

Affected Packages

euvd peppermint no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Peppermint's API (apps/api/src/lib/jwt.ts) verifies session tokens using a symmetric HMAC-signed JWT whose signing key is supplied as an environment value defined in the distributed docker-compose.yml. Because that key is a fixed, committed constant rather than a per-deployment generated secret, every default deployment shares the same signing material. This is a textbook CWE-798 (Use of Hard-coded Credentials): the security of HMAC-based JWTs depends entirely on the secrecy of the signing key, and a publicly known key collapses the entire authentication scheme - signatures no longer prove the server issued the token. The affected component is identified by CPE cpe:2.3:a:peppermint-lab:peppermint:*:*:*:*:*:*:*:* covering all versions up to and including 0.5.5.

Know when Peppermint gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (VulnCheck) PRIMARY 9.3 CRITICAL
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
vuln.today AI 9.8 CRITICAL

Remote unauthenticated token forgery via a publicly known secret yields full account/admin takeover, so PR:N/UI:N and C/I/A:H; scope unchanged within the app.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
None
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
High
Vulnerable system: Availability
High
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

Peppermint through 0.5.5 contains a hardcoded JWT signing secret in docker-compose.yml that allows unauthenticated attackers to forge session tokens for any account. Attackers can use the published secret to mint valid tokens for arbitrary user IDs and access protected endpoints without credentials.

Executive ViewAI

Why It Matters

Peppermint helpdesk platforms through version 0.5.5 ship with a hardcoded JWT signing secret embedded in their docker-compose.yml, enabling any attacker to forge valid authentication tokens for any user-including administrators-without credentials. Any organization self-hosting Peppermint exposes its entire support ticketing system to unauthorized read, write, and delete access. The 'exploit' is trivially the publicly documented secret itself.

Business Impact: Severe
Compensating Controls

No vendor-released patch identified at time of analysis. Immediate interim mitigations: (1) Rotate the JWT signing secret in docker-compose.yml to a strong random value and restart the application; (2) restrict network access to Peppermint to internal networks only, eliminating unauthenticated internet exposure; (3) implement Web Application Firewall rules to detect and block anomalous token patterns if external access is unavoidable; (4) enable detailed audit logging of all API access and user session creation for forensic review. These controls reduce blast radius but do not eliminate the vulnerability in affected versions.

Threat Intelligence Overview

EPSS Score
0.3%
Top 72% exploitable
Prevalence
Low
niche self-hosted open-source helpdesk, modest deployment footprint
Data Quality
7 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity CRITICAL
CISA KEV No
Public POC No
EPSS 0.3%
Patch available No
Active threat No
Deciding rule
CRITICAL severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Out-of-Cycle
Exploitation
None
System Exposure· derived
Open
Automatable
Yes
Human Impact
Very High
Technical Impact
Total

Priority Score

46
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +46
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy