Bug Bounty During the Holidays: How to Keep Hunting When Everyone's Off

The last two weeks of December can look like a dead zone on a bounty platform. Reports sit in "New." Slack channels go quiet. The researcher who usually beats you to every IDOR is somewhere with bad Wi-Fi. None of that means the bugs took a holiday. It means the queue moved, and hunters who plan around the slowdown tend to walk into January with a stack of resolved reports and a head start.

What Actually Changes, and What Doesn't

What changes: response times, triage staffing, deployment schedules, and the number of duplicates you fight over. Many companies run change freezes so engineering can rest, which means a fix may not ship until the second week of January even after a valid report is confirmed.

What doesn't change: scope, attack surface, and payout policies. Your target's API still accepts the same parameters on December 27 as it did on November 27. A business logic flaw doesn't care that the office is empty. The practical takeaway is to spend your energy on work that doesn't depend on a fast reply.

Choose Targets That Stay Staffed

Not every program sleeps. Companies whose revenue can't pause — payments, e-commerce during peak season, hosting providers, SaaS with uptime commitments, anything with a security operations center staffed around the clock — usually keep someone watching the queue. Programs that pay a platform to handle first-response triage also keep moving, even when the final decision waits.

A few signals worth checking before you invest a week:

• A published response-time commitment on the program page.
• A triage team credited on the platform rather than an in-house team only.
• Recent activity: resolved reports, hall of fame updates, a changelog that shows the program is alive.
• Clear escalation instructions for critical issues.

The reverse matters too. If a small program has announced a shutdown until January, a critical finding may sit untouched for two weeks. Report it anyway, use the escalation path if one exists, and don't mistake silence for disinterest.

Bug Classes That Suit a Quiet Window

Some categories of bugs fit a period when nobody wants a 3 a.m. page better than others. Look for issues that reward careful reading instead of heavy traffic:

• Access control gaps. IDORs, missing permission checks on newer endpoints, role confusion between admin and support accounts.
• Business logic abuse. Coupon stacking, refund flows, trial extensions, quantity manipulation, referral loops.
• Race conditions. Double-spend, duplicate redemption, balance updates that ignore concurrency.
• Exposed non-production assets. Staging hosts, forgotten subdomains, dev APIs, old storage buckets that still resolve.
• Secrets in public code. API keys inside JavaScript bundles, mobile app strings, public repositories.
• Documentation drift. Endpoints that exist but never made the docs, or parameters the docs describe and the server never enforces.

These rarely require aggressive automation, which is exactly the point.

Keep Your Testing Quiet

Peak traffic season is a bad time to point a loud scanner at production. Rate-limit yourself, use accounts you own, and avoid destructive payloads — no mass deletion, no forcing state changes on other people's data. If you trip something critical, stop testing, capture what you need, and report it rather than proving the entire impact chain.

Change freezes also mean a bug that would normally be patched in a day may linger for weeks. Document it thoroughly on the first pass so nobody has to come back to you for basic details while they're the only person online.

Write for the One Person on Call

A holiday triager is often the only security person working, juggling normal on-call duties between family commitments. A short, complete report gets confirmed faster than a long one. Include:

1. A one-sentence summary of the vulnerability and where it lives.
2. Impact, stated in business terms rather than CVSS math.
3. Minimum steps to reproduce, numbered, using an account you created.
4. Evidence: a request and response pair or a short screen recording, nothing more.
5. A suggested fix, if you have one.

Skip the drama and the speculation about worst-case scenarios. If the finding is critical, say so in the first line and use the program's escalation channel or platform support in addition to the report itself.

Use the Slow Weeks to Compound

Free time is best spent on work that pays off later. Refresh your asset inventory for two or three programs you know well. Read the changelogs and API documentation you've been putting off all year. Rewrite the reports that got closed as informational so you understand what the triager actually wanted. Practice a new area — mobile, cloud configuration, GraphQL — in a lab rather than against production.

Reviewing your own rejections is underrated. Patterns show up quickly: the same weak impact statement, the same missing proof, the same misread of scope.

Expect Silence and Plan for It

Assume two to four weeks for anything non-urgent. Track submissions with dates in a simple sheet, set a calendar reminder for the seven-to-ten-day mark, and send one polite follow-up. Daily comments don't speed anything up and can push your report toward the bottom of a tired person's list.

A Workable Holiday Week Plan

Keep the schedule boring and repeatable:

• Days 1–2: Recon on three programs with clear SLAs. Save the asset lists for January.
• Days 3–4: Manual testing on the highest-value surface, one bug class at a time.
• Day 5: Write and send reports before the weekend, not after.
• Days 6–7: Study, tooling, and cleanup. No new testing against production.

If you also happen to run a program or sit on a triage desk, remember the other side of this: a careful, well-written report that lands between Christmas and New Year is a gift worth handling promptly once you're back at your desk.

Photo: Polina Tankilevitch / Pexels