CVE-2025-26787
📋 TL;DR
A logic error in Keyfactor SignServer container startup resets certificate access controls to 'allowany' on every restart instead of only initial setup. This allows any user with a valid trusted client certificate to connect, bypassing admin-configured restrictions. Affects SignServer versions before 7.2 running in containerized deployments.
💻 Affected Systems
- Keyfactor SignServer
📦 What is this software?
Signserver by Keyfactor
⚠️ Risk & Real-World Impact
Worst Case
Unauthorized users with any valid client certificate gain administrative access to SignServer, potentially signing malicious certificates or accessing sensitive signing operations.
Likely Case
Temporary privilege escalation where users with valid certificates gain unintended access until next admin reconfiguration, potentially accessing signing functions they shouldn't.
If Mitigated
Minimal impact if proper network segmentation and certificate management controls prevent unauthorized certificate holders from accessing the system.
🎯 Exploit Status
Exploitation requires a valid client certificate, but any trusted certificate works. No special tools or techniques needed beyond normal certificate authentication.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 7.2
Vendor Advisory: https://support.keyfactor.com/hc/en-us/articles/33997706776987-SignServer-security-advisory-Container-vulnerability-CVE-2025-26787-fixed-in-version-7-2
Restart Required: Yes
Instructions:
1. Upgrade SignServer to version 7.2 or later. 2. Update container images to use patched version. 3. Restart all SignServer containers. 4. Verify certificate access controls remain after restart.
🔧 Temporary Workarounds
Manual certificate restriction after each restart
allManually reconfigure certificate restrictions using Admin CLI after every container restart
signserver setproperty GLOBAL allowany false
signserver setproperty GLOBAL allowedcertificates "CERT1,CERT2"
Disable container auto-restart
linuxPrevent automatic container restarts that trigger the vulnerability
docker update --restart=no signserver-container
🧯 If You Can't Patch
- Implement strict network access controls to limit who can reach SignServer containers
- Enforce certificate revocation checking and maintain tight certificate lifecycle management
🔍 How to Verify
Check if Vulnerable:
Check if container restarts reset certificate access to 'allowany' by testing with different client certificates after restartCheck Version:
signserver --version | grep 'SignServer'Verify Fix Applied:
After patching, restart container and verify certificate restrictions persist using Admin CLI: 'signserver getproperty GLOBAL allowany' should return false📡 Detection & Monitoring
Log Indicators:
- Multiple 'allowany' property resets in startup logs
- Authentication attempts from unexpected certificate subjects after container restart
Network Indicators:
- Increased authentication attempts from diverse certificate sources following container restarts
SIEM Query:
source="signserver" AND "allowany" AND "true" AND "startup"