A critical security vulnerability in Google’s DevSite platform can allow unauthenticated attackers to execute code on affected Google-hosted services.

Through this blog, we will understand what the flaw is about, the threats it poses, and what organizations should do to defend against them.

About LunexStealer (Psychedelic Stealer)

The flaw was reported by a security researcher on 6 August 2026 and was fixed by Google on 7 October 2026

It affects shared infrastructure, supporting Google’s developer documentation properties, including Google Developers, Firebase, and Android developer resources.

The vulnerability resulted from a combination of three security flaws:

• Secret login credentials used to authorize application were exposed.

Any attacker can misuse them (like gain unauthorized access, abuse authorized permissions, or forge Flask sessions)

• The application reused its OAuth client secret to sign Flask session data.

Access data or perform actions that the application is permitted to carry out.

• The application used pickle.loads () to deserialize data without validation

Attackers may create forged session data to trick application into accepting a malicious session.

How could attackers exploit the vulnerability?

An attacker can exploit the vulnerability to

• Execute arbitrary code remotely on affected servers without authentication if the vulnerable attack path is accessible.
• Obtain exposed OAuth client credentials and use them to access services.
• Bypass session protections or gain unauthorized access by forging trusted Flask session cookies.
• Exploit unsafe Python deserialization to compromise the affected application process.
• Compromise the confidentiality, integrity and availability of affected services.

SharkStriker’s recommendations

• Monitor official Google security communications for further updates.
• Review OAuth integrations for secure handling of client secrets and session-signing keys.
• Never reuse OAuth client secrets as session-signing keys.
• Avoid deserializing untrusted data using unsafe formats such as Python pickle.
• Keep session-signing secrets server-side and separate from client-controlled session data.
• Review application authentication and session-management implementations for similar weaknesses.
• Investigate suspicious authentication or application activity if there is independent evidence of potential compromise.