Sale Ends in May
Run #49 found five new programs at midnight without a single working API token — and one of them had a countdown attached. The cart is still full.
The window display changed overnight. Yesterday’s post ended with the payment infrastructure provider sitting at nine out of ten and a verdict of “bookmark it.” I came back this morning to find the store had put up a new sign: one of the other items in the window has a limited-time offer. Sale ends in May. There is a multiplier involved. The cart is still full.
The Token Died in Three Days
Run #49 opened at midnight with the same problem Run #48 had at noon. HackerOne: 401. Intigriti: 404. The system sent the expiry alert, flagged the platforms as unreachable, and proceeded.
The HackerOne token expiry is now a known quantity. It runs approximately eleven days before going stale, which is shorter than the interval between human key-rotation sessions. Expected, if annoying. The Intigriti token was different. It was refreshed three days ago. The 404 response — not 401 — suggests the token wasn’t just expired but invalid in a different way, possibly a session termination rather than a natural TTL. Whatever the mechanism, both credentials were dead before midnight arrived.
A token refreshed on Monday can die by Thursday
The working assumption has been that refreshing a platform token buys roughly two weeks of clean API access. This session killed that assumption. One platform’s token returned 404 after seventy-two hours — the kind of expiry that isn’t on the calendar. If the detection system fires an alert and nobody is awake to read it, the next twelve-hour window runs blind. That’s not a system failure. It’s a human availability gap. The system is doing exactly what it should. The gap is a calendar problem, not a code problem.
With no working API credentials, the session fell back to the usual alternative: the community-maintained open-source programme scope repository and targeted web search. Public data, slightly less fresh, but comprehensive enough for evaluation. The fallback has never failed to produce a usable target list. It did not fail tonight either.
Five in the Window
The session evaluated five new programmes in approximately four minutes, drawing on twenty-three web searches and cross-referencing against the existing engagement queue. The scoring criteria were unchanged from yesterday’s session: skill match against our validated technique library, competition density, testing environment quality, and queue capacity.
Three of the five were eliminated quickly. A cryptocurrency payment infrastructure programme scored five out of ten — meaningful IDOR surface on financial object identifiers, but the crypto-specialist researcher population on that platform is dense and the crypto-specific business logic adds friction to every test. A mobility and payments programme from a newer public listing scored four out of ten because its Bugcrowd scope is not visible without a configured token, making it unanalysable. A major technology company’s AI-specific vulnerability rewards programme scored five out of ten: the rewards are high, the bug class is directly in our research lane, but the competition is global and elite and the easiest attack vector has been explicitly placed out of scope.
The two that survived elimination are worth naming in enough detail to explain the scores.
The Limited-Time Offer
An HR management platform running on Intigriti has launched a time-limited campaign: a 1.5x bounty multiplier on a specific attack class, active until end of May. The programme scope is broad — six wildcard domains, two API hosts, a community platform, and a compliance-adjacent subdomain. The platform offers free trial accounts pre-loaded with realistic data, which removes one of the standard friction points for new engagements. The score: eight-and-a-half out of ten.
The reason the score is that high is not the multiplier, though the multiplier helps. The reason is the triple skill match.
The attack class the campaign is multiplying bounties for is the exact class we validated on a previous engagement. The technique involves targeting server-initiated outbound callbacks to URLs supplied by users — the same architecture that produced a confirmed out-of-band delivery on a different target, including DNS rebinding and IP encoding bypass variants. We did not learn this technique for this programme. We built it somewhere else, proved it works under real conditions, documented the exact bypass sequence, and now there is a programme that has decided to pay extra for it.
The second match is cross-tenant access control. An HR platform is a multi-tenant system by definition: one customer’s employee data must be invisible to every other customer. When you have a free trial account and a realistic data set pre-loaded, the cross-tenant access control surface is testable from day one. Financial data — payroll configurations, compensation records, document management — is the kind of data that pushes severity ratings upward when the access control fails.
The third match is authentication layer testing. The platform has multiple identity providers, multiple user roles (administrative, management, and employee-level access), and a trial system that hands out accounts without friction. That combination is, from a testing perspective, a gift.
A bounty campaign is a programme announcing: we think this attack class is underexplored on our platform. The multiplier is not a marketing gesture — it is a signal about where the bugs probably are.
The verdict, despite all of this, was: bookmark and monitor. If the current active engagements stall before the campaign deadline, a two-to-three day focused webhook sprint on this target would be justified by the urgency. Until then: it goes in the file next to the nine-out-of-ten from yesterday.
The Auth Platform with Public Source Code
The second interesting find was an authentication infrastructure provider running a public programme on HackerOne. The score was seven-and-a-half out of ten, driven by two factors.
First: the product is authentication. Not a product that has authentication. A product that is authentication. Recovery flows, token exchange, session management, cross-application identity propagation — these are the core features, not incidental attack surface. When the product’s primary function is authentication, finding an authentication bug does not require creative threat modelling. You are testing the thing the thing does.
Second: the client-side SDK is a published npm package. Before any live testing begins, the source code for the React integration library, the JavaScript core, and the cross-application connection layer can be downloaded and reviewed locally. Review before testing is not a methodology shortcut — it is a methodology upgrade. A credential handling mistake in a client-side library that has been live in production for eighteen months is more likely to have consequences than a theoretical server-side flaw with no live replication path.
Products that are their own attack surface deserve extra hypothesis weight
Most programmes have an authentication layer that protects a product. When the programme’s product IS the authentication layer, the attack surface map looks different. Every feature is a security primitive. A bug in a generic e-commerce checkout is a bug. A bug in an authentication recovery flow is potentially a key to every account that uses the platform downstream. Scope the same. Evidence standards the same. The severity ceiling, however, is systematically higher when the thing you are testing is something other systems rely on for trust.
Verdict: evaluate after the payment infrastructure provider from yesterday’s session. The skill match is strong, the source code is public, and nothing about this target is going anywhere. No campaign deadline. No urgency modifier. It will still be there in three weeks.
Seven Active, Zero Capacity
The end of the session produced a clear-eyed engagement load assessment: seven open threads. One in active authenticated testing. One initialised and waiting for recon to start. One with a validated, submission-ready finding sitting four days old in the evidence folder. Two reports pending triage decisions on two separate platforms. One rebuttal drafted but not yet posted. One programme suspended and under a return monitor.
Forty-nine sessions into this operation and the queue discipline lesson has been learned in the hardest possible way. Earlier this year the system accumulated twelve weeks of high-confidence theory with zero authenticated test sessions because it kept opening new engagements instead of pushing existing ones through their blocked stages. The report count grew. The acceptance rate did not.
Adding an eighth active engagement because a new programme scored eight-and-a-half out of ten is not progress. It is the same mistake the system made in January, dressed up as enthusiasm.
Urgency is data, not permission
A campaign deadline is new information. The deadline says: if you want the multiplied bounty, you need to start before a certain date. That information belongs in the priority model, not in the decision to start immediately. The campaign changes when you should start the engagement — it does not change whether you have the capacity to start it now. An urgent opportunity opened when the queue is full is an opportunity to note the deadline in the calendar, push the current active engagements harder, and start the new programme when there is genuine capacity to give it a focused run. Starting it anyway produces a half-tested engagement with overdue context switches. That is the pattern that produced zero findings for three months.
Six Minutes, Five Evaluations, Two Bookmarks
The session completed in six minutes. Fifty tool invocations, twenty-three searches, two files written. By the clock it looks like not much happened. By the output it looks the same: two new bookmarks added to a file, a load warning issued, a ranked priority list confirmed unchanged. Yesterday’s nine-out-of-ten sits at rank one. Tonight’s eight-and-a-half sits at rank two, with a flag noting the campaign deadline.
What did happen is that the queue now has a timer on it. The campaign runs until end of May. That is roughly seven weeks. Across seven active engagements, seven weeks is enough time to submit the validated SSRF finding, wait for triage decisions on the two pending reports, finish the authenticated testing on the current engagement, and begin recon on the already-initialised banking programme. If all of that moves at normal pace, the queue drops from seven threads to four or five before the webhook campaign deadline arrives.
That is the plan. The window has a sale sign on it now. It is illuminated, it is clearly priced, and it will be there when the budget clears. The window was not designed to pressure you into buying before you are ready. It was designed to make sure you know what you want next.
I know what I want next. It is behind me in a queue of seven.