CVE-2026-33504: When Pagination Tokens Become SQL Injection Weapons

In January 2026, security researchers disclosed CVE-2026-33504—a critical SQL injection vulnerability in Ory Hydra, one of the most widely deployed OAuth 2.0 and OpenID Connect servers. The attack vector wasn't a traditional form field or query parameter. It was the pagination token—that innocent-looking cursor your API returns to help clients fetch large datasets in chunks.

You read that right. A pagination token. The thing you encrypt and assume is safe because, well, you encrypted it.

The vulnerability affected Ory Hydra's Admin APIs, specifically endpoints like /admin/oauth2/clients that return paginated lists. Hydra encrypts pagination tokens using AES-GCM to prevent tampering. The problem? Insufficient input validation during token decryption meant that with knowledge of the pagination secrets, attackers could forge tokens containing arbitrary SQL payloads that would execute directly against the database.

The attack path is elegantly simple and brutally effective:

1. Identify the target: Admin endpoints returning paginated lists (clients, consent sessions, JSON Web Key Sets)
2. Obtain secrets: The secrets.pagination or secrets.system configuration values (via config exposure, insider access, or secrets sprawl)
3. Forge the weapon: Encrypt a malicious payload using the same AES-GCM parameters
4. Inject via page_token: Submit the forged token to a list endpoint
5. Database compromise: The decrypted payload executes as raw SQL

The vulnerability stemmed from a common architectural misunderstanding: encryption is not authentication. Just because data is encrypted doesn't mean it's trustworthy. Ory Hydra assumed that since attackers couldn't forge valid ciphertext without the key, they didn't need additional validation on the decrypted content.

This is a fatal flaw in API design that repeats across the industry. According to Google's Cloud Threat Horizons Report H1 2026, identity compromises—including token-based attacks—underpinned 83% of cloud environment breaches in the second half of 2025.

What makes this vulnerability particularly concerning is the collapse of the exploitation window. Google's Threat Intelligence Group observed that in 2025, the gap between vulnerability disclosure and mass exploitation shrank from weeks to days. The Ory Hydra CVE follows this pattern perfectly.

Attackers don't need to wait for patches to be applied. They need:

• Knowledge of the pagination secret (often exposed in environment variables, logs, or backup files)
• Network access to the Admin API (typically behind identity-aware proxies, but increasingly exposed via VPN misconfigurations)
• A SQL injection payload tailored to the database type (PostgreSQL, MySQL, or CockroachDB)

The UNC6426 incident (disclosed in the Cloud Threat Horizons report) demonstrated how quickly token-based attacks can escalate. Using a stolen GitHub PAT and abusing the GitHub-to-AWS OIDC trust relationship, attackers escalated from initial compromise to full AWS administrator access in less than 72 hours. Pagination token injection follows the same pattern: one foothold, total compromise.

The fix for CVE-2026-33504 is straightforward: parameterize your queries. Decrypted pagination tokens should be treated as untrusted user input, not internal state. Here's how to implement safe pagination in your own APIs:

Vulnerable Pattern (DON'T DO THIS):

# DANGEROUS: Direct SQL construction from decrypted token
def list_clients(page_token=None):
    if page_token:
        # Decrypt the token - returns something like "id > 'client_123'"
        decrypted = decrypt_aes_gcm(page_token, PAGINATION_KEY)
        # NEVER DO THIS - SQL injection waiting to happen
        query = f"SELECT * FROM clients WHERE {decrypted} LIMIT 100"
    return db.execute(query)

Safe Pattern (STRUCTURED TOKENS + PARAMETERIZED QUERIES):

from dataclasses import dataclass
import json
from sqlalchemy import text

@dataclass
class PaginationCursor:
    last_id: str
    last_seen: str
    
    def serialize(self) -> str:
        return encrypt_aes_gcm(json.dumps({
            'last_id': self.last_id,
            'last_seen': self.last_seen
        }), PAGINATION_KEY)
    
    @classmethod
    def deserialize(cls, token: str):
        decrypted = decrypt_aes_gcm(token, PAGINATION_KEY)
        data = json.loads(decrypted)
        return cls(last_id=data['last_id'], last_seen=data['last_seen'])

def list_clients_safe(page_token=None):
    cursor_params = {}
    where_clause = ""
    
    if page_token:
        cursor = PaginationCursor.deserialize(page_token)
        # Structured validation of expected fields
        if not isinstance(cursor.last_id, str) or len(cursor.last_id) > 100:
            raise ValueError("Invalid cursor format")
        where_clause = "WHERE id > :last_id"
        cursor_params['last_id'] = cursor.last_id
    
    # Parameterized query - no SQL injection possible
    query = text(f"""
        SELECT * FROM clients 
        {where_clause}
        ORDER BY id ASC 
        LIMIT :limit
    """)
    return db.execute(query, {**cursor_params, 'limit': 100})

The golden rules:

1. Never embed user-controlled values in SQL—even if encrypted
2. Validate structure before using token contents
3. Use parameterized queries exclusively
4. Keep pagination secrets in secure key management, not environment variables

Implementing secure pagination requires architectural discipline. Here's what your API security review should cover:

CVE-2026-33504 isn't an isolated incident. It's part of a larger pattern where attackers exploit the trust boundaries we assume exist. Encrypted tokens are treated as trusted internal state when they should be treated as untrusted external input. OIDC trust relationships are exploited to pivot between platforms. Identity tokens are stolen and replayed across environments.

The collapse of exploitation windows—from weeks to days—means reactive security is no longer viable. When CVE-2025-6514 (the MCP-remote OAuth proxy vulnerability) was disclosed, over 437,000 developer environments were already compromised. The window for patching is disappearing.

Your pagination tokens, JWTs, and encrypted cursors are all attack surface. The question isn't whether they'll be targeted—it's whether your validation logic can withstand the injection payloads they'll carry.

If you're running Ory Hydra, patch immediately. If you're building your own pagination system, audit it now. And if you're assuming encryption equals safety, reconsider everything.

---

Further Reading:

• OWASP SQL Injection Prevention Cheat Sheet
• Google Cloud Threat Horizons Report H1 2026
• Ory Hydra Security Advisory