--- title: I Found a $90k Remote Code Execution Vulnerability in Google description: A bug bounty writeup details how a Flask session cookie on developers.google.com leaked its own signing secret (a Google OAuth client_secret stored inside the... canonical: https://daily.dev/posts/i-found-a-90k-remote-code-execution-vulnerability-in-google-ovhg0aanu twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: I Found a $90k Remote Code Execution Vulnerability in Google | daily.dev og:description: A bug bounty writeup details how a Flask session cookie on developers.google.com leaked its own signing secret (a Google OAuth client_secret stored inside the... og:url: https://daily.dev/posts/i-found-a-90k-remote-code-execution-vulnerability-in-google-ovhg0aanu og:image: https://api.daily.dev/og/posts/OvHG0AANU.png og:image:alt: I Found a $90k Remote Code Execution Vulnerability in Google og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # I Found a $90k Remote Code Execution Vulnerability in Google **[Hacker News](https://daily.dev/sources/hn)** · 5 min read · 0 upvotes · 0 comments ## Summary A bug bounty writeup details how a Flask session cookie on developers.google.com leaked its own signing secret (a Google OAuth client_secret stored inside the session payload), allowing cookie forgery and ultimately unauthenticated remote code execution via pickle deserialization in the OAuth callback flow. The same vulnerable key signed sessions across seven Google domains including firebase.google.com and developer.android.com. The finding was verified using time.sleep() as a side-channel proof, reported through Google's bug bounty program, and paid $90,000 (S0 RCE, base $75,000 x1.2 for report quality). Fix involved rotating secrets, using independent high-entropy session keys, keeping OAuth flow state server-side, and dropping pickle for client-facing data. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### how can a Flask session cookie be forged to achieve remote code execution If the Flask SECRET_KEY used to sign session cookies is derivable from data stored inside the session itself, an attacker can recompute the signature and forge arbitrary session content. On developers.google.com, the session carried a pickled OAuth2WebServerFlow object containing the client_secret, which was also the Flask signing key, so a forged session could inject attacker-controlled pickle data into the server's pickle.loads call, achieving unauthenticated code execution. _daily.dev surfaces writeups like this for developers hardening Flask session handling against deserialization attacks._ ### why is using pickle to store data in a web session cookie dangerous Pickle's REDUCE opcode names a callable and its arguments, and unpickling executes that call directly, so deserializing attacker-controlled pickle data is equivalent to unauthenticated remote code execution once an attacker can produce a validly signed cookie. The recommended fix is dropping pickle for anything crossing a client boundary in favor of a schema-checked, data-only format, and keeping sensitive objects server-side with only an opaque reference in the cookie. _developers weighing serialization formats for session or cookie data can track this kind of risk via daily.dev._ ### how much did Google pay for the Flask session pickle RCE bug bounty report Google paid $90,000 for a Server-Side (S0) remote code execution finding in a Normal Google Application (T2), calculated as a $75,000 base reward multiplied by 1.2 for exceptional report quality. The vulnerability affected the shared DevSite platform, with a single leaked signing key valid across seven Google domains including firebase.google.com, developer.android.com, and source.android.com. _security researchers benchmarking bounty payouts for RCE findings can follow similar disclosures on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 91 comments across hackernews, lobsters (as of 2026-10-12). **TL;DR:** Most discussion centers not on the technical finding itself but on whether the writeup was AI-generated and what that means for credit and trust, alongside a separate debate about why bug bounties exist; the vulnerability's root cause (a signing key embedded in its own cookie, plus pickle deserialization) draws some surprise but little real technical pushback. **Sentiment:** 10% positive · 35% mixed · 55% skeptical **The case for** - Some argue the bounty payout structure (flat fee plus report-quality multiplier) rewards disclosure regardless of how 'easy' the bug seems in hindsight. - A few note that using LLMs effectively to find real vulnerabilities still requires significant prior expertise and that dismissing the result outright is uncharitable. - One commenter calls it a genuinely nice catch despite the writing issues. **The pushback** - Many found the writeup's prose had unmistakable LLM-authored phrasing, which undermined trust in the author's claimed role in the discovery. - Several are skeptical that storing a signing secret inside its own cookie and using pickle for client-facing data reflects a basic, embarrassing lapse in review. - Disagreement over whether bug bounties mainly exist to outcompete a black market for exploits or simply to surface bugs that wouldn't otherwise be reported through normal channels. - Some feel repetitive LLM writing patterns in posts are becoming tiresome and reduce their willingness to read such writeups. **By community** - hackernews (heated): A long, contentious thread split between debating whether the post (and possibly the finding itself) was LLM-generated, and a separate sprawling argument over the true economic purpose of bug bounty programs. - lobsters (mixed): Very light engagement, with one commenter expressing disappointment that Google's security posture has declined. **Hottest debate:** Whether the writeup (and possibly the underlying research) was substantially produced by an LLM, and what that implies about crediting the human author. **Open questions** - Does using an LLM to assist in vulnerability research diminish the credit due to the human researcher? - Is there truly no black market for serverside web vulnerabilities like this one, as claimed by one commenter's detailed argument? **Highlights** > This is probably my highest-rated comment on HN: https://news.ycombinator.com/item?id=43025038 It's the product of direct interviews with bounty people, FAANG/MAG7 blue teamers, and black market participants. If you want more, there's also an interview online that we did with Mark Dowd, who is one of the best known CNE vendors to the NATO IC. You can just Google [SCW Mark Dowd]. I'm happy to go into more detail, but, like I said, you didn't really respond to my comment in any way that I could expand on. Feel free to disagree with me in some kind of specific way. This really is simple: if you work in this space, you already know that there's essentially no black market at all for serverside web bugs. But there's a $90k bounty for this one, and 5-figure bounties for others. Reconcile those two facts. > — [tptacek on hackernews · 1 comments](https://news.ycombinator.com/item?id=50063210) > Because it's not drawing. It's not even drawing in the abstract: nobody drew anything. There are no brush strokes. You can watch the steps diffusion models take and at no point is there anything that resembles "drawing". Drawing with Photoshop absolutely resembles drawing. Photobashing with Photoshop does not. Photography also isn't drawing. These things are all distinct. That's the actual point I was trying to get at here by invoking Photoshop. Image models differ from text in that text models do resemble something closer to what people are actually doing, but you just have to accept that analogies have limitations here. Just like you can draw or not draw with Photoshop, you can use Claude in ways where you're really driving it like a tool to do work, and you can also use Claude in a "fix the bug" sense where you're doing absolutely nothing other than paying $200/mo and typing occasionally. But whereas Photoshop introduces nuance to what it means to draw or make art by introducing different levels of involvement versus remixing and etc., Claude and Stable Diffusion utterly decimate nuance in a thermonuclear blast that plunges us into a nuance Nuclear Winter, by offering for perhaps the first time a way for the computer to do nearly all of the generalized "thinking" while you sit on your ass and argue on HN. (Reminder for everyone to check on their agents.) Trust me, I use LLMs, I get the idea. I can "vibe code". On my workbench is a laptop running an entire desktop system including an application suite that I really didn't write. It would be cool to go online and say "Hey guys check out this cool desktop environment I wrote!" but I won't because I really didn't. It was just an experiment. Did I put in effort? Yes. Was it coding? Nope, it was closer to management, though I did write some code. The experiment was some mix of failure and success, but what I would never do is say that I wrote it. I may some day blog about the experience and the pros and cons and how I feel about the resulting code, but for right now I feel the Internet is full of enough slop and most people who I respect are thoroughly tired of hearing about LLMs all day (I am too at this point, though I am not saying I find none of it interesting.) Do I think all LLM use absolutely must be disclosed? Actually no, and especially right now I understand why some people don't. I know I just said LLMs and diffusion models destroy all nuance, but that's not strictly true. My line in the sand is this: if nobody can tell overtly that you're using LLMs, and you can demonstrate your own understanding of what you are doing, then I don't care. In that case it's more of a concern for the person using the LLM, because the real concern in that case is becoming dependent on LLMs and being unable to write software/etc. without them anymore. But that isn't really my concern. If I can tell your blog post was written by Claude within the first few sentences you have completely failed to demonstrate anything but your willingness to deceive people. How can you not feel some shame putting yourself on the By-line of a blog post you didn't write? I mean it's written in first person! And I know damn well that not everyone can immediately pick out LLM-generated text, but that isn't entirely the point either. It's one thing to use LLMs to do work, but the point of a blog post isn't just the text, blogging is a form of (formerly...) human expression. It just doesn't make any sense to put Claude-slop blog posts right next to human-authored blog posts, any more than it makes sense to put AI-generated images next to drawings. The point isn't the pixels and isn't the words. That contrasts with code, because with code, the point really is the code, and other stuff is secondary. I can't tell you whether this person found this vulnerability and triaged it or Claude did. I don't even care. However, I don't trust a blog post they didn't write anyway. This is a long comment, but it's hard to make it > — [jchw on hackernews · 1 comments](https://news.ycombinator.com/item?id=50061094) > how does something like this pass code and design reviews. is this code written by ai (the buggy code). Not only was the key that signs the cookie inside the cookie it self but it's using pickle which even model weights are moved away from. I'm a little flabbergasted at the noob nature of this root cause. > — [option\_greek on hackernews · 4 comments](https://news.ycombinator.com/item?id=50060111) > The cookie is "what caught my eye." not realistic phrasing The cookie contained a pickle-serialized payload, "which was bad enough on its own." maybe not best practice but not bad on it's own Flask session cookies are signed", not encrypted," so the... LLMs love to tell you what things aren't, as an emphasis on what they are > — [lgats on hackernews · 1 comments](https://news.ycombinator.com/item?id=50058654) > handing clients access to an LLM gets them beginner level code, easily. same with beginner level exploits. an RCE against google is not a "beginner level exploit". If you've seen AI generated code, I can tell you that AI generated security findings also have that "beginner" smell. an expert who knows what they're doing has to drive them to look at the right places, and use the experts preferred method. > — [pluto\_modadic on hackernews](https://news.ycombinator.com/item?id=50058817) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50052638) · 172 points · 90 comments - [lobsters](https://lobste.rs/s/mldt0o/finding_90_000_remote_code_execution) · 25 points · 1 comments ## Similar posts on daily.dev - [How I Discovered a Complete CSRF Protection Bypass on a Major Crypto Exchange And What Happened Next](https://daily.dev/posts/how-i-discovered-a-complete-csrf-protection-bypass-on-a-major-crypto-exchange-and-what-happened-next-hinaktgox) · InfoSec Write-ups · 0 upvotes · 0 comments - [GitHub.dev flaw lets attackers steal OAuth tokens in one click](https://daily.dev/posts/github-dev-flaw-lets-attackers-steal-oauth-tokens-in-one-click-tounneovz) · The Next Web · 0 upvotes · 0 comments - [The AI app builder your team trusts has a root-level backdoor](https://daily.dev/posts/the-ai-app-builder-your-team-trusts-has-a-root-level-backdoor-tzeyqwasx) · CSO Online · 0 upvotes · 0 comments - [Critical Langflow Vulnerability Allows Remote Code Execution](https://daily.dev/posts/critical-langflow-vulnerability-allows-remote-code-execution-vnn8uugk6) · AI Cyber Insights · 1 upvotes · 0 comments --- Tags: [#google](https://daily.dev/tags/google), [#oauth](https://daily.dev/tags/oauth), [#flask](https://daily.dev/tags/flask) [View this post on daily.dev](https://daily.dev/posts/i-found-a-90k-remote-code-execution-vulnerability-in-google-ovhg0aanu) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"I Found a $90k Remote Code Execution Vulnerability in Google","url":"https://daily.dev/posts/i-found-a-90k-remote-code-execution-vulnerability-in-google-ovhg0aanu","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/i-found-a-90k-remote-code-execution-vulnerability-in-google-ovhg0aanu"},"datePublished":"2026-10-12T17:16:32.072Z","dateModified":"2026-10-12T23:03:26.872Z","description":"A bug bounty writeup details how a Flask session cookie on developers.google.com leaked its own signing secret (a Google OAuth client_secret stored inside the...","image":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","thumbnailUrl":"https://media.daily.dev/image/upload/s--qPvKM23u--/f_auto/v1722860399/public/Placeholder%2009","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/i-found-a-90k-remote-code-execution-vulnerability-in-google-ovhg0aanu","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"google,oauth,flask","timeRequired":"PT5M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"I Found a $90k Remote Code Execution Vulnerability in Google"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/i-found-a-90k-remote-code-execution-vulnerability-in-google-ovhg0aanu#faq","mainEntity":[{"@type":"Question","name":"how can a Flask session cookie be forged to achieve remote code execution","acceptedAnswer":{"@type":"Answer","text":"If the Flask SECRET_KEY used to sign session cookies is derivable from data stored inside the session itself, an attacker can recompute the signature and forge arbitrary session content. On developers.google.com, the session carried a pickled OAuth2WebServerFlow object containing the client_secret, which was also the Flask signing key, so a forged session could inject attacker-controlled pickle data into the server's pickle.loads call, achieving unauthenticated code execution. daily.dev surfaces writeups like this for developers hardening Flask session handling against deserialization attacks."}},{"@type":"Question","name":"why is using pickle to store data in a web session cookie dangerous","acceptedAnswer":{"@type":"Answer","text":"Pickle's REDUCE opcode names a callable and its arguments, and unpickling executes that call directly, so deserializing attacker-controlled pickle data is equivalent to unauthenticated remote code execution once an attacker can produce a validly signed cookie. The recommended fix is dropping pickle for anything crossing a client boundary in favor of a schema-checked, data-only format, and keeping sensitive objects server-side with only an opaque reference in the cookie. developers weighing serialization formats for session or cookie data can track this kind of risk via daily.dev."}},{"@type":"Question","name":"how much did Google pay for the Flask session pickle RCE bug bounty report","acceptedAnswer":{"@type":"Answer","text":"Google paid $90,000 for a Server-Side (S0) remote code execution finding in a Normal Google Application (T2), calculated as a $75,000 base reward multiplied by 1.2 for exceptional report quality. The vulnerability affected the shared DevSite platform, with a single leaked signing key valid across seven Google domains including firebase.google.com, developer.android.com, and source.android.com. security researchers benchmarking bounty payouts for RCE findings can follow similar disclosures on daily.dev."}}]} ```