Yesterday I discovered a security flaw in OpenAI’s web session management. I reported it through their bug reporting process, managed by a site called Bugcrowd. The response was quick, probably from an AI bot, and dismissive. It classified the issue as P5 (Informational), the lowest category of security findings.

The issue I found is simple. When someone logs into a website, the system issues credentials that allow their browser to access the site without requiring them to authenticate with every request. Anyone who obtains a valid token may be able to access that account without knowing their password.

I found this issue while using OpenAI’s platform site to check my usage. I copied an authenticated request from my browser’s developer tools. The request included a bearer token, which authorizes any request with no further checking. I was able to execute this request from a command line to retrieve my usage and billing information.

I then went to OpenAI’s security settings and selected “Log out all”. As expected, my browser session was terminated. However, the copied request continued to work from the command line using the same token for another 40 minutes.

This behavior contradicts OpenAI’s documentation, which states that all active API Platform sessions are immediately invalidated when a user selects “Log out of all devices” in the admin page.

Why does this matter?

Consider the situation where someone’s computer has been compromised by malware. The malware could steal the session token and transmit it to a criminal, who could then use it to access the victim’s account. Or the token is inadvertently disclosed in a public forum. Even if the account owner discovered the compromise immediately, logging out of all sessions would not terminate the criminal’s access. The criminal could extract sensitive information or consume the victim’s usage credits.

I disputed the classification on Bugcrowd. Would a company consider it merely informational if a compromised employee token continued to provide access to its systems after the employee had explicitly revoked all sessions? Would an individual whose account was wide open on the Internet be sanguine about waiting 40 minutes for the credentials to expire? Would an OpenAI employee like to post their token in the comments section here?

A logout mechanism that fails to revoke access is not a mere inconvenience. It leaves users exposed precisely at the moment when they are trying to protect themselves.

The broader problem

Individuals and businesses increasingly depend on a small number of technology providers for services that handle substantial amounts of personal and commercially sensitive information. Yet we have little visibility into how these providers secure our data and limited ability to protect ourselves when their security controls fail.

The public also has limited recourse when security vulnerabilities are discovered. Companies establish their own security policies, appoint intermediaries to assess reported weaknesses, and ultimately decide whether and when those weaknesses warrant correction. Automated evaluations like Bugcrowd’s may be useful for OpenAI, but they do not consider the risks faced by users.

Vulnerability assessments need to examine the actual risk to users. Internal testing should verify that the system behaves as described. OpenAI provided a security control that explicitly promised to terminate all active sessions. Yet my experience showed that previously issued credentials continued to work after that control was used. That is a serious failure.

OpenAI should address this immediately and ensure its system behaves as its documentation states. Security controls must work as advertised. That is the basic testing that providers should perform. Users should not have to learn that there was insufficient due diligence after an account has been compromised.