[HackerNotes Ep. 187] Dupes, Harnesses of Harnesses, and Internet Melting Bugs

Hacker TL;DR

• Depth stopped being a moat. Everyone points Codex and Claude at the same scope and finds the same bugs, so dupe rate is way up. The new edge is niche scope and program-specific expertise fed into the prompt, not going deeper by hand.

• "Your request has been blocked" on 5.6 Sol is very often a compaction error, not a real refusal. Downgrade to 5.5, let it compact, switch back up to 5.6 and keep going.

• Ultra finds more bugs but burns tokens. Have Codex analyze one of your Ultra sessions, then bake the efficiency wins into AGENTS.md: batch tool calls, reuse subagents instead of spinning new ones, and keep the cache warm. Same quality, fewer tokens.

• The real bottleneck is no longer tokens, it is you. Scaling subs pushes the pain into triage, report writing, and mediation, so build a harness of harnesses that keeps itself maxed and shore up the pipeline behind it.

We do subs at $25, $10, and $5, premium subscribers get access to:

– Hackalongs: live bug bounty hacking on real programs, VODs available
– Live data streams, exploits, tools, scripts & un-redacted bug reports

You can also find some hacker swag here.

Need a Pentest? We just launched CTBB Pentests!

Hack full time? Check out the Full-Time Hunter’s Guild!

The Dupe Problem: Depth Stopped Being a Moat

The way you used to win was depth. You would go hard, get deep into a component nobody else had the patience for, find a bug and think "no one else is getting this." That moat is mostly gone. Sol and Codex cover a lot of ground fast, so the bug you would have found alone at midnight now gets found by three people running an agent. Dupe rate goes up, motivation goes down.

The thing is, the game changed and stayed the same at the same time. The people winning events right now are doing exactly what winners always did, just through AI. Two patterns keep showing up:

• Point the agent at niche surface. The hunters landing more bugs than everyone else are running AI on a small part of the scope nobody else is looking at. Same instinct as always, different interface.

• Seed it with your own expertise. Feed the prompt your past reports and program notes so the agent inherits real program-specific knowledge. That is the difference between a generic "find bugs" run landing five and an informed run landing ten.

Pro Tip: stop trying to out-depth the model on shared scope. Your leverage is knowing where to point it, not reading the source faster than it does. Find the niche areas where bugs live and prompt straight down those rabbit holes.

The Harness of Harnesses

AI-powered hacking is built for ADHD brains. Eight panes of Claude open, jumping between them for four hours, and your brain is mush, even for someone who can lock in and hack twelve hours straight without blinking. The fix is not "try harder," it is to stop being the one manually keeping the subs busy.

The goal state: a harness that keeps multiple subscriptions maxed out on its own, continuously, without you directing every run. Manually telling agents to stay busy is the least scalable thing you can do. A hackbot harness that stays maxed will find less and less over time, but that is the bar rising, not the model getting worse. 5.6 Sol is still strong enough to go crazy deep on internet melting bugs, so the move is to keep it maxed rather than let it idle.

Once you scale subs, the constraint moves. It stops being tokens and becomes your own triage. Everything behind the bug finder has to level up: the validation pipeline, the report writer, and eventually your mediation responses. A few patterns worth stealing:

• Automate the mediation grind. A good setup takes a report, reads the mediation request, goes and finds the evidence, and drafts a response you clean up. The lazy version is exporting the HackerOne report as markdown and telling the agent "respond to this." It feels gross running everything through AI, but the responses are better because the model pulls the real request and evidence.

• Scale needs old accounts. A brand new account applying for Trusted Access for Cyber gets rejected on account age. Make the accounts now so they have aged by the time you want to scale in a month or two.

• Consider paying someone to keep it alive. Off-keeper bots stay up for a while then die, and re-setup plus re-login is the annoying part. A VA or someone from the community whose whole job is keeping agents logged in and generating traffic across a hundred programs could easily pay for itself.

Pro Tip: if you actually intend to scale, provision the boring stuff ahead of the tokens. Age your accounts, build the report writer, and automate mediation before you are drowning in validated-but-unwritten findings.

How Many Times Do You Push Back

When 5.6 Sol tells you there is no bug, how many times do you push back before you believe it?

Some hunters stop at one or two. Others will do it over and over. The event story that makes the case: the model insisting there was no bug, several times, met with "no, there's definitely a bug here, I know there is," and around the third or fourth pass it produced a real critical RCE. Most people would have stopped after the third refusal.

The nuance is that blind persistence and earned persistence are not the same. Pushing hard and getting a crit is a lot more defensible when it is backed by pre-existing subject matter expertise, knowing where the holes are in a product you have worked before. The open question is whether that even matters anymore. If saying "yes there is" on everything keeps paying out, maybe stubbornness alone is the heuristic. The counterweight is tokens: none of us have infinite budget, and every extra "keep looking" is effort not spent on other scope. Nobody has calibrated exactly how much to gaslight the model yet.

Pro Tip: back your pushback with a reason. "I know there is a bug here because this class of bug lives in this component" spends tokens well. "Try again" on a hunch, forty times, is just burning budget you could point somewhere with a real lead.

"Request Has Been Blocked" Is Usually Compaction

Practical tip that will save you an afternoon. "Your request has been blocked" from 5.6 Sol is very often not about your content at all. The block is a compaction error: the model used for compaction on 5.6 appears to carry stronger safety filters, so a long session trips it during compaction, poisons the thread, and it stays unusable. Panic-copying everything into another model does nothing, because the target was never the problem.

The fix does not touch your prompt or your engagement:

1. Downgrade to 5.5.

2. Let it compact on 5.5.

3. Switch back up to 5.6 Sol and keep going.

This matches what is on the Codex tracker: a long Sol thread strands on "Request blocked" after a compaction, a fresh thread works fine, and dropping to 5.5 to get through compaction unsticks it.

Making Ultra More Token Efficient

Ultra is the orchestration mode: instead of one agent it fans out subagents that work in parallel and synthesize. It finds meaningfully more bugs, and putting effort on Ultra helps in both Codex and Claude. The cost is that it eats tokens, and everyone is token starved on Sol.

The move to steal: take a real multi-hour Ultra session and ask the model "I love Ultra, it finds way more bugs, but it burns through tokens, can you find any efficiencies?" You get a list back, then codify the good ones in AGENTS.md under a rule that says "when you run Ultra mode, do these things." The wins that matter:

• Batch operations into fewer tool calls instead of chattering one call at a time.

• Reuse subagents rather than spinning up new ones with large fresh context every time.

• Keep the cache warm so repeated context does not get re-paid.

Same bug-finding quality, materially fewer tokens. Exactly what you want when a second subscription is not an option but you still want Sol's depth.

Pro Tip: point the model at its own logs. Feed a heavy Ultra session back in, ask for efficiency wins with zero quality loss, then bake the good ones into AGENTS.md so every future run inherits them.

Frontier Class Vulnerabilities

The anchor of the episode is Shubs post, Frontier class vulnerabilities: it gets worse before it maybe gets better.

The core of it: a wave of extremely critical vulnerabilities is now being discovered with GPT-5.6 Sol with very little human input or supervision. Where the previous generation of models needed steering, harnesses, and skill, Sol operates far more autonomously. The reference case is @hash_kitten and wp2shell, the pre-auth WordPress core RCE Sol iterated to in roughly six to ten hours. The line that stuck: even S-tier researchers now sometimes spend hours or days understanding a bug that took the model less time to find than it takes them to comprehend.

The directive Shubs gave his team is the quote of the article:

The strategic point: think bigger about what your attack surface looks like. Going for the biggest possible shots is a lot more achievable now, and if you do not find them first, someone does, which means either lost bounty or a catastrophic event for the company. The near-term responsibility Shubs frames is raising the cost of discovering critical vulnerabilities in software. The goals have not changed, the stakes have.

The framing to hold onto: the thing to be grateful for in bug bounty right now is a very material way to convert tokens directly into dollars. Almost nobody else in the AI economy has that. Everyone else is building an app, chasing users, figuring out monetization. Hunters already have the pipeline, demand is effectively infinite, and the whole job is ramming tokens down it as hard as possible.

Pro Tip: the general lesson is that trying things got cheap. Anytime you think "it would be nice to have this," build it. Anytime you think "I should try this," tell the agent to try it. Most people are still budgeting effort at pre-frontier-model prices.

Resources

• Frontier class vulnerabilities - Shubs on the shift to autonomously-found critical bugs and the internet melting bugs directive.

• wp2shell writeup - Adam Kues on the pre-auth WordPress RCE chain built with 5.6 Sol.

• Trusted Access for Cyber - apply with your oldest existing account, not a fresh one, since account age drives rejections.

That's it for the week, keep hacking!