GHSA-8F6J-263M-G72X: OCSP Revocation Checking Bypass in Apple App Store Server Python Library

The Apple App Store Server Python Library (app-store-server-library) provides utility classes to securely verify transactions, subscriptions, and server notifications. When checking certificates, the SignedDataVerifier component establishes a trust chain using cryptographic verification. Applications can configure online certificate validation to check whether Apple's signing certificates have been revoked.

This verification process uses the Online Certificate Status Protocol (OCSP) to retrieve status updates from Apple's certificate authority. When the enable_online_checks parameter is active, the library evaluates these responses. The client is responsible for validating that the response is both cryptographically sound and fresh.

Because the library fails to perform freshness checks, it accepts stale OCSP packets. This deficiency exposes applications utilizing the library to impersonation and authentication bypasses. The failure allows revoked certificate chains to be treated as trusted if the attacker has captured historical validation responses.

The underlying security issue is mapped to CWE-295 (Improper Certificate Validation) and CWE-299 (Improper Check for Certificate Revocation). To prevent replay attacks, the OCSP standard (RFC 6960) defines metadata fields inside the SingleResponse structure. These fields are thisUpdate (specifying when the status was known to be correct) and nextUpdate (indicating when newer status information becomes available).

When verifying an OCSP response, software must evaluate the local system clock against the thisUpdate and nextUpdate values. If the current time is outside this interval, the assertion is stale and must be rejected. The vulnerable implementation in _ChainVerifier.check_ocsp_status evaluated structural and cryptographic details but omitted temporal checks.

Because of this omission, any cryptographically valid OCSP assertion from the past showing a status of OCSPCertStatus.GOOD satisfies the library's verification condition. The logic never checked whether the validity window of the OCSP assertion had expired. Consequently, an assertion captured when a compromised certificate was valid remains trusted forever in the eyes of the library.

An analysis of the vulnerable codebase in version 3.1.1 shows the incomplete validation loop in appstoreserverlibrary/signed_data_verifier.py:

# Vulnerable Code Path (v3.1.1)
for single_response in ocsp_resp.responses:
    builder = ocsp.OCSPRequestBuilder()
    builder = builder.add_certificate(
        cert.to_cryptography(), issuer.to_cryptography(), single_response.hash_algorithm
    )
    req = builder.build()
    if (
        single_response.certificate_status == ocsp.OCSPCertStatus.GOOD
        and single_response.serial_number == req.serial_number
        and single_response.issuer_key_hash == req.issuer_key_hash
        and single_response.issuer_name_hash == req.issuer_name_hash
    ):
        # Success is declared without verifying time bounds
        return

The conditional checks verify the cryptographic status and request hashes, but never access single_response.this_update_utc or single_response.next_update_utc.

The patched version (3.1.2) corrects this by introducing timezone-aware temporal validation and an acceptable clock skew threshold:

# Patched Code Path (v3.1.2)
now = datetime.datetime.now(datetime.timezone.utc)
if (
    single_response.certificate_status == ocsp.OCSPCertStatus.GOOD
    and single_response.serial_number == req.serial_number
    and single_response.issuer_key_hash == req.issuer_key_hash
    and single_response.issuer_name_hash == req.issuer_name_hash
    and single_response.this_update_utc is not None
    and now + _ChainVerifier.MAX_SKEW >= single_response.this_update_utc
    and single_response.next_update_utc is not None
    and single_response.next_update_utc >= now - _ChainVerifier.MAX_SKEW
):
    # Response is accepted only if it is within the valid time-window
    return

This modification ensures the validation logic rejects stale assertions. This fix is complete because it relies on the absolute cryptographic authority of the UTC timestamps embedded inside the signed responder data.

Exploiting this vulnerability requires a network-positioned attacker capable of routing outbound traffic or intercepting DNS requests. To execute the attack, the adversary must have access to a compromised or leaked developer certificate that Apple has revoked, along with a historically recorded OCSP 'GOOD' response packet for that certificate.

When the vulnerable application processes a JWS signed by the revoked developer certificate, it initiates an outbound OCSP request to Apple's responder URL. The attacker intercepts this connection using methods like DNS spoofing or local gateway redirection.

The attacker responds with the pre-captured, cryptographically signed OCSP 'GOOD' packet. Because the library is vulnerable to replay attacks, it verifies the signature of the status packet, ignores the expired date, and treats the revoked certificate as valid.

The impact of this flaw is classified as medium, with a CVSS v4.0 score of 6.9. While the confidentiality of systems is not compromised, the integrity of application states is degraded. An attacker can exploit this weakness to submit false or forged purchase data.

Applications relying on verification checks to unlock paywalled resources or validate in-app purchases may process invalid transactions. This scenario is problematic if high-value services are granted based on signatures created using revoked developer keys.

The vulnerability is constrained to environments enabling enable_online_checks=True. This configuration is necessary to protect against compromised certificate authority paths. The mitigation provided in the patch restricts exploitation by enforcing adherence to RFC 6960 validation.

Remediation requires upgrading the app-store-server-library package to version 3.1.2 or higher. The patch introduces temporal bounds validation using timezone-aware UTC datetime operations, blocking replay attacks.

# Upgrade dependency using pip
pip install --upgrade app-store-server-library>=3.1.2

For applications that cannot apply immediate library upgrades, developers can disable online checks as a temporary workaround. However, this action stops revocation checking entirely, leaving the system vulnerable to processing revoked certificates. This workaround is only advised when alternative network protections or gateway-level OCSP validation are implemented.