Altair GraphQL Client for Desktop didn’t verify HTTPS certificates before version 8..5. This means that if you used it on public WiFi or a sketchy network, attackers could see all your GraphQL queries, variables, response data—and even your login tokens. They can even hijack your Altair Cloud account or swap out payment pages. A fix landed in v8..5, so update _now_.


Altair is a popular, user-friendly GraphQL client—think Postman, but for GraphQL APIs. You can:

Even connect to Altair Cloud for team sync.

But until version 8..5, the desktop app version didn’t check if the HTTPS certificates on the API endpoints were real and valid. That is a huge security gap—also known in security terms as _missing certificate validation_ or _Trust On First Use_ (TOFU).

The Short Version

CVE-2024-54147 is an identifier for the security bug in the desktop Altair GraphQL Client where HTTPS server certificates weren't validated. This allowed attackers connected to the same network (or able to mess with DNS) to intercept, read, or even change your API requests and responses.

Official CVE details:

Vulnerable versions: Altair before v8..5 (desktop only)

- Patched in: v8..5
- Reference: GitHub advisory GHSA-65v2-2mj7-vx43

Real World Scenario

Say you’re working on a coffee shop’s WiFi, using Altair to test a production GraphQL API with your precious Authorization tokens. Because Altair didn’t validate certificates, a hacker on the same WiFi hotspot could:
- Harvest all your request/response data (think: sensitive user data, secrets, schemas)

How Did the Bug Work?

In simple terms, when you connect to an HTTPS API, the “S” is supposed to mean you’re using TLS encryption _with identity verification_. That’s what stops an imposter server from pretending to be your real API.

Altair desktop’s code did _not_ check that the server’s certificate was valid and signed by a trusted Certificate Authority (CA). So if an attacker “tricked” your computer into connecting to their server (using ARP spoofing, rogue DNS, etc.), Altair wouldn’t notice. It would trust any server speaking HTTPS.

Code Snippet Example

Here’s what insecure (deprecated) Node.js HTTPS request code can look like—you can see rejectUnauthorized: false which disables validation:

// Bad: disables certificate checking
const https = require('https');

const agent = new https.Agent({
  rejectUnauthorized: false // DO NOT DO THIS!
});

https.get('https://api.example.com/graphql';, { agent }, res => {
  // ...
});

The correct way is to _not_ set this, or explicitly ensure rejectUnauthorized: true (which is the default):

// Good: HTTPS certificates are validated
const https = require('https');

https.get('https://api.example.com/graphql';, res => {
  // Safe against MITM
});

The fix in Altair’s code restores proper validation.

Attacker joins the same WiFi network as a victim running Altair.

2. Performs a Man-in-the-Middle attack—maybe ARP spoofing, DNS poisoning, or operating a rogue hotspot.
3. When the victim queries https://api.yourcompany.com/graphql via Altair, attacker intercepts the traffic using a tool like mitmproxy, presenting their own bogus HTTPS cert.

Attacker harvests the sensitive API requests, responses, and tokens.

6. If the victim is also logged into Altair Cloud, attacker can use the session token to hijack the Altair Cloud account.
7. Attacker can also modify the JSON response—for example, swap out a payment link with a phishing site.

That’s much worse than just leaking data; it could compromise entire teams, or production systems if tokens are re-used.

Exploit PoC (for educational purposes)

Set up mitmproxy on WiFi traffic, then configure DNS or ARP to redirect resolve api.example.com to attacker’s IP.

# Example: mitmproxy running on attacker's machine
mitmproxy --mode transparent

In the logs, you’ll see raw GraphQL queries, headers, and auth tokens Altair users are sending—without any certificate warning.

Altair Cloud account users (possible full compromise)

Web or browser-based Altair versions depend on the browser’s certificate checks, so they’re not affected.

How Can You Stay Safe?

Update _now_ to v8..5 or later:
Download latest Altair GraphQL Client

Never trust public WiFi for API or auth work without a VPN

- Reset/rotate sensitive tokens if you used Altair on public WiFi before upgrading

References & Further Reading

- Original advisory: GHSA-65v2-2mj7-vx43
- Altair release notes: v8..5
- CVE record: CVE-2024-54147 at cve.org
- What is mitmproxy?

Conclusion

Altair is a great tool for GraphQL—but this security bug could have cost users a lot.
Make sure you update, check your sensitive tokens, and _never disable certificate checking_ in your own code!

If you work on Electron/Node desktop apps, always test for proper HTTPS handling: your users trust you with their credentials and data—don’t let them down.


_Feel free to share this post with your team or link to it in your security docs._

Timeline

Published on: 12/09/2024 19:15:14 UTC