Uncovering Intercom Misconfigurations: From Ignored Widgets to High-Impact Vulnerabilities

Introduction (My Journey)

When I first started bug hunting, I often came across websites with Intercom chat widgets. Honestly, I usually ignored them — they looked harmless, just another third-party plugin.

But one day, I decided to dig deeper. I asked myself: What happens if these widgets aren’t configured properly? That small question led me down a rabbit hole. After analyzing several real implementations, I discovered three high-impact misconfigurations that can put sensitive customer support conversations at risk.

These findings highlight an important lesson: third-party integrations are often underestimated attack surfaces. Misconfigurations can easily turn them into an attacker’s entry point.

Below, I present the 3 misconfigurations I discovered, using example.com as a placeholder target to protect affected organizations.

1. Intercom Identity Misconfiguration — Unauthorized Access to Support Chats

Summary

Some organizations fail to enforce Intercom Identity Verification. Without it, attackers can impersonate any user (customer or employee) by booting the Intercom widget with an arbitrary email address.

Technical Details

Intercom provides a secure mode (user_hash or JWT) to ensure that only authenticated users can claim an identity. When this is not enforced, anyone can run the following in the browser console:

Intercom('boot', { email: 'victim@example.com' });

This loads the entire support chat history of the chosen user, including live updates of ongoing conversations.

Properly configured companies respond with an error such as:

error: Missing user_hash or intercom_user_jwt. A valid user_hash or intercom_user_jwt is required...

But misconfigured deployments simply expose the data.

Impact

• Unauthorized access to customer or employee support chats.

• Exposure of PII, confidential discussions, or internal troubleshooting details.

• Continuous leakage of live data.

• Legal and compliance risks (GDPR, HIPAA, etc.).

Attack Scenario

An attacker identifies a public Intercom widget on example.com. They open the console and boot the widget with the email of a known customer. Immediately, they can:

• Read all historic conversations.

• Watch live messages as they are sent.

• Impersonate the user to request sensitive information from support staff.

Mitigation

Enable Identity Verification in Intercom → Settings → Security.

Generate user_hash server-side using HMAC-SHA256.

Pass user_hash to Intercom boot alongside the user ID/email.

Restrict Messenger to authenticated users only if it contains sensitive data.

Test the Fix by running Intercom('update', { email: 'victim@example.com' }); in console — impersonation should now fail.

2. Broken Access Control — Session Leakage Between Users

Summary

Improper session teardown in Intercom allows the next logged-in user on the same browser to inherit the previous user’s chat session.

Steps to Reproduce

User A logs into example.com, opens Intercom, and chats with support.

User A logs out.

User B logs in using the same browser session.

When User B opens the Intercom widget, User A’s entire chat history appears.

Root Cause

Intercom session tokens (intercom-session-*, intercom-id-*) persist in local storage/cookies and are not invalidated on logout.

Impact

• Breach of user privacy and confidentiality.

• Exposure of sensitive chat data to unauthorized users.

• Risk of session fixation and impersonation.

Attack Scenario

• In a shared environment (e.g., internet café, family device, corporate terminal), a user logs into Intercom and chats with support about a private issue.

• They log out, but the next user unknowingly inherits the session and can read the chat history.

Mitigation

• On logout, execute:

Intercom('shutdown');

• Then re-initialize Intercom with the new user context.

• Clear all Intercom session cookies/local storage on logout.

• Follow Intercom’s documentation for resetting the widget securely.

3. Intercom Chat Session Persists After Logout

Summary

Even after a user logs out of example.com, the Intercom chat widget remains active in the browser. The previous chat history continues to be visible and interactable, without authentication.

The session only terminates when a new user logs in, at which point it is replaced.

Steps to Reproduce

User A logs into example.com and chats via Intercom.

User A logs out.

Without logging in again, the Intercom widget remains active — exposing User A’s history.

Only when User B logs in does User A’s session get replaced.

Impact

• Sensitive chats remain accessible after logout.

• Any unauthorized party using the same browser/device can read prior conversations.

• Risk of social engineering, as exposed chat history may reveal internal processes.

Attack Scenario

An employee logs into example.com from a shared device, chats with support about a production outage, and logs out. Hours later, another person opens the same site in that browser and instantly sees the previous sensitive chat messages.

Mitigation

• Ensure logout events trigger hard reset of Intercom (shutdown()).

• Reinitialize only when a new session is established.

• Provide a guest view or blank state when no user is authenticated.

Conclusion

For years, I overlooked Intercom during my bug hunting. But after analyzing it closely, I found three critical misconfigurations:

Identity Verification not enforced → User impersonation.

Session leakage between users → Broken Access Control.

Session persistence after logout → Data exposure without authentication.

These findings prove that security issues often hide in plain sight, especially in third-party integrations. A small misconfiguration can expose massive amounts of sensitive data.

If you run Intercom on your website, double-check your configuration today — don’t assume the defaults are safe.