JWT and PHPUnit Vulnerabilities: What Happens If Left Unpatched? A Real Case Study

Two critical PHP vulnerabilities (CVE-2025-45769 & CVE-2026-24765) discovered in a new maintenance client site: JWT token forgery and RCE risks. A detailed technical guide on vulnerability response, attack scenarios, and best practices.

Struggling with Security Vulnerability Response?

"We received a vulnerability alert, but how urgent is it really?" "What if updating breaks our existing functionality...?" "I don't understand what specific risks we're facing."

Many web administrators face these concerns. While neglecting security vulnerabilities can lead to serious damage, improper handling can also bring systems to a halt.

In this article, we'll detail two critical PHP vulnerabilities discovered and resolved at a client site under a new maintenance contract signed in February 2026. This real-world case study provides practical guidance for anyone dealing with similar vulnerability responses in their maintenance services.

Detailed Analysis of Detected Vulnerabilities

CVE-2025-45769: Weak Encryption in firebase/php-jwt

Affected Versions: firebase/php-jwt < v7.0.0 (Client site was using v6.11.1) Severity: High (CVSS Score: 8.1) Disclosure Date: July 31, 2025

This vulnerability arises from the use of weak cryptographic algorithms in the JWT (JSON Web Token) signature verification process. If exploited, attackers could potentially forge authentication tokens that should otherwise be secure.

// Vulnerable code example (v6.11.1 and earlier)
$payload = [
    'user_id' => 123,
    'exp' => time() + 3600
];

// Signature with weak encryption algorithm
$jwt = JWT::encode($payload, $key, 'HS256'); // Vulnerable versions allow signature to be compromised

CVE-2026-24765: Unsafe Deserialization in phpunit/phpunit

Affected Versions: phpunit/phpunit < 11.5.53 (Client site was using 11.5.46) Severity: Critical (CVSS Score: 9.8) Disclosure Date: January 27, 2026

Improper use of PHP's unserialize() function allows injection of malicious objects. This vulnerability poses high risks in development and CI/CD environments, potentially leading to Remote Code Execution (RCE).

Actual Response Process and Results

Step 1: Current State Investigation and Risk Assessment

As part of the initial security assessment when the maintenance contract began, we investigated all package dependencies for vulnerabilities using the composer audit command.

# Vulnerability detection
$ composer audit

Found 2 security vulnerability advisories affecting 2 packages:
- firebase/php-jwt (CVE-2025-45769)
- phpunit/phpunit (CVE-2026-24765)

Step 2: Update Work in Test Environment

To minimize impact on the production environment, we first executed updates in the test environment.

# Update dependencies
$ composer update firebase/php-jwt phpunit/phpunit

# Total of 13 packages updated including related packages
Upgrading firebase/php-jwt (v6.11.1 => v7.0.2)
Upgrading phpunit/phpunit (11.5.46 => 11.5.53)
# 11 other related packages automatically updated

Step 3: Comprehensive Test Execution

# Run full test suite
$ ./vendor/bin/phpunit

PHPUnit 11.5.53
.......................... 216 / 216 (100%)

Time: 00:02.847, Memory: 24.00 MB

OK (216 tests, 1,247 assertions)

All 216 tests on the client site passed successfully, confirming no impact on existing functionality.

Step 4: Deployment to Production Environment

# Production environment work
$ composer install --no-dev --optimize-autoloader
$ php artisan config:cache
$ php artisan route:cache

Specific Risks if Left Unaddressed

Attack Scenario for firebase/php-jwt Vulnerability

Scenario 1: JWT Token Forgery Attack

1. Attacker exploits weak encryption algorithm vulnerability
2. Analyzes valid JWT tokens and bypasses signature verification
3. Creates forged tokens with administrator privileges
4. Gains unauthorized access to the system and steals confidential data

// Attack example (conceptual illustration)
$malicious_payload = [
    'user_id' => 1, // Administrator ID
    'role' => 'admin',
    'exp' => time() + 86400
];

// Forged token generation exploiting vulnerability
$forged_jwt = malicious_jwt_forge($malicious_payload);

Impact Scope:

• Complete compromise of user authentication system
• Leakage of personal information and confidential data
• Abuse of administrative functions through unauthorized privilege escalation

phpunit/phpunit Deserialization Attack

Scenario 2: Remote Code Execution Attack

1. Attacker creates malicious PHPT file
2. Executed during test coverage processing in CI/CD environment
3. Malware executed through unserialize() vulnerability
4. Arbitrary code execution on server becomes possible

// Malicious object example
class MaliciousObject {
    public function __wakeup() {
        // System command execution
        system('rm -rf /var/www/html/*'); // Dangerous!
    }
}

Impact Scope:

• Intrusion into development and production environments
• Source code theft and tampering
• Complete takeover of server control

Common Failure Patterns in Security Response

Failure Pattern 1: "Misjudging Urgency"

In past maintenance projects, vulnerabilities in phpunit, which is only used in development environments, were underestimated. However, if the CI/CD environment is compromised, it can become an entry point to the production environment.

Solution:

• Treat development environment vulnerabilities with the same importance as production
• Respond immediately to CVSS scores of 7.0 or higher
• Don't underestimate the scope of impact

Failure Pattern 2: "Production Failures Due to Insufficient Testing"

In the past, we've seen cases where authentication functionality stopped due to API specification changes during a major version upgrade of firebase/php-jwt (v6→v7).

// Code that worked in v6
$decoded = JWT::decode($jwt, $key, ['HS256']);

// In v7, the second parameter specification changed
$key_object = new Key($key, 'HS256');
$decoded = JWT::decode($jwt, $key_object);

Solution:

• Be especially careful with major version upgrades
• Test authentication components under identical production conditions
• Prepare rollback procedures in advance

Failure Pattern 3: "Overlooking Dependencies"

When updating one package, other packages may be updated in a chain reaction. In this case, 11 related packages were updated simultaneously.

Solution:

• Check the scope of impact with dry-run before composer update
• Include all updated packages in test scope
• Consider staged updates

Security Best Practices

1. Regular Vulnerability Monitoring

# Weekly vulnerability check
#!/bin/bash
echo "$(date): Security audit started"
composer audit
if [ $? -ne 0 ]; then
    echo "Vulnerabilities detected. Immediate action required."
    # Add Slack notifications, etc.
fi

2. Automated Security Scanning

We recommend implementing automated scanning using GitHub Actions or GitLab CI.

# .github/workflows/security.yml
name: Security Audit
on:
  schedule:
    - cron: '0 9 * * MON'  # Every Monday at 9 AM
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: 8.2
      - name: Security Audit
        run: composer audit

3. Standardizing Update Procedures

Security Support Provided by Maintenance Services

Cases like this are frequently discovered when new maintenance contracts begin. With previous development companies or in-house operations, security response is often deprioritized.

What Fivenine Design's Maintenance Services Provide:

Comprehensive Security Monitoring

• Complete security assessment at contract initiation
• Monthly vulnerability scanning and reporting
• Immediate response based on urgency level
• Regular security report submissions

Safe Update Procedures

• Pre-verification in test environment (standard)
• Risk mitigation through staged deployment
• Rapid rollback capability
• Detailed update work reports

In this case, our initial assessment at contract start discovered firebase/php-jwt vulnerabilities that had been neglected for about 6 months and phpunit/phpunit vulnerabilities neglected for about 3 weeks. Continuous maintenance services prevent such oversights.

Summary and Next Steps

Responding to security vulnerabilities requires not just technical work, but also risk assessment, prioritization, and test strategy. Here are the key points learned through this response:

Critical Points:

• Early Detection: Regular vulnerability scanning minimizes damage
• Proper Assessment: Accurate understanding of CVSS scores and impact scope
• Staged Response: Careful procedures from test to production environments
• Comprehensive Testing: Verification of all related functionality

Expected Results from Improved Security Framework:

• Significant reduction in incident occurrence rate
• Shortened response time (average 70% reduction)
• Improved system uptime
• Enhanced customer trust

Immediate Actions to Take: First, check your current vulnerability status with the composer audit command. If vulnerabilities are found, verify CVSS scores and proceed with responses at appropriate priority levels.

If your company in Kanagawa is facing challenges with site maintenance and security response, please consult Fivenine Design's maintenance services. We identify potential risks through initial assessments and support continuous safe operations.