Skip to content

fix: use random nonce per call in AES-GCM onboarding signature (ISS-2528895)#411

Open
rzp-slash[bot] wants to merge 1 commit into
masterfrom
fix/aes-gcm-nonce-reuse
Open

fix: use random nonce per call in AES-GCM onboarding signature (ISS-2528895)#411
rzp-slash[bot] wants to merge 1 commit into
masterfrom
fix/aes-gcm-nonce-reuse

Conversation

@rzp-slash
Copy link
Copy Markdown

@rzp-slash rzp-slash Bot commented May 31, 2026

Summary

Fixes a critical AES-GCM nonce reuse vulnerability in generateOnboardingSignature (ISS-2528895, HackerOne #3754503).

  • Root cause: $iv = substr($key, 0, 12) — the IV was always derived from the first 12 bytes of the AES key, meaning every encryption call for a given partner reused the exact same key-nonce pair. AES-GCM forbids this (NIST SP 800-38D §8.3).
  • Impact: An attacker observing any two onboarding_signature values from partner authorize URLs (exposed via browser history, Referer headers, server logs, Sentry, etc.) could recover the GHASH key and forge a cryptographically valid signature for any submerchant_id — without knowing the client_secret.
  • Fix: Replace the static IV with random_bytes(12) (CSPRNG). The random IV is prepended to the output so receivers can extract it: output format is now hex(iv || ciphertext || tag) where the first 24 hex chars are the IV.

Changes

  • src/Utility.php — generate fresh 12-byte IV per encryption call; prepend IV to ciphertext output
  • tests/OAuthTokenClientTest.php — replace hardcoded deterministic assertion (which relied on the broken static IV) with behavioral assertions: valid hex output, minimum length, and uniqueness across calls

⚠️ Action Required

  1. Server-side (auth.razorpay.com): Update signature decryption to read the first 24 hex chars as the IV before decrypting. Previously the IV was re-derived from the key; now it is transmitted in the payload.
  2. Partner client_secret rotation: Signatures captured before this fix remain exploitable under the old key material via the Forbidden Attack. Guidance should be issued to all affected partners to rotate their client_secret.
  3. Other SDKs: Apply the equivalent fix to razorpay-java, razorpay-node, and razorpay-ruby (same nonce derivation flaw exists in all four).

Test plan

  • $iv = random_bytes(12) generates a unique nonce on every call
  • Output hex string is at least 56 chars (24 IV + ciphertext + 32 tag)
  • Two calls with identical inputs produce different signatures
  • Existing integration tests pass with updated assertions

Related: ISS-2528895 | HackerOne #3754503

🤖 Generated with Claude Code

Static IV derived from the key (substr($key, 0, 12)) was reused for
every encryption call, enabling keystream recovery and authentication
tag forgery via the GHASH Forbidden Attack with just two captured
onboarding_signature values.

Fix: replace static IV with random_bytes(12) and prepend the IV to the
ciphertext output (iv || ciphertext || tag) so receivers can extract the
IV for decryption. Output format is unchanged (hex string), but now
includes a 12-byte IV prefix (first 24 hex chars).

Server-side validation at auth.razorpay.com must be updated to read the
first 24 hex chars as the IV before decrypting. Partners should also
rotate their client_secret as previously captured signatures remain
exploitable under the old key material.

Co-authored-by: ankitdas13 <ankit.das@razorpay.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant