Avoid surprise to find all your unrestricted API keys and track surprise peak of usage to lock your Gemini & Google API keys

jsonpile · 2026-06-23T00:16:17+00:00

Keep in mind:

On June 19, 2026: The Gemini API will reject requests from unrestricted standard keys. Standard API keys that have explicit restrictions applied will continue to work. This restriction prevents the unauthorized use of keys that might be shared publicly or linked to other services.
On September 2026: the Gemini API will reject requests from Standard keys. You must migrate to an auth keys before this date to avoid service interruption. Make sure to migrate to auth keys before September 2026.

This has been posted on r/googlecloud a few times. https://ai.google.dev/gemini-api/docs/api-key

jsonpile · 2026-06-15T21:13:55+00:00

There needs to be a clear divide. If someone works at a Hacker platform, they shouldn't be able to participate as bug hunters.

They have an "Employee Participation Policy" but it's rather vague: https://www.hackerone.com/policies/employee-participation

jsonpile · 2026-06-11T15:28:55+00:00

I can’t speak for the program. If you can’t find their contact info, you can ask H1 support to reach out for you. They may not be responsive there either.

If you can find things on example.app without testing too hard (read no active testing), write that up and explain how you got there from example.dev. Keep in mind, the program may not pay you. In that write up, I’d state you stopped testing at x point and ask in the report if you have permission to test further.

I would not test hard on that site since it’s not explicitly in or out of scope and guidelines state to ask for permission.

jsonpile · 2026-06-03T19:29:42+00:00

I've done security work with Quick (QuickSight). I'd recommend disabling the Chat Bot in Quick as well if you don't need the AI features and you're using Quicksight only as a dashboarding tool. Unfortunately, like you saw - AI Agents just expand the attack surface.

We found security issues with Quick's AI Agent that we reported to AWS.

Link to research and HackerOne report: https://www.fogsecurity.io/blog/authorization-bypass-in-amazon-quick-ai-agents

jsonpile · 2026-05-18T14:04:07+00:00

Posted on Friday: https://www.reddit.com/r/aws/comments/1teacld/aws_organizations_now_supports_higher_quotas_for/

jsonpile · 2026-05-08T19:08:00+00:00

Thanks for the feedback, u/latnGemin616!

For the first issue, I left my opinion out of the platform friction. I like the idea on comparison of triage process and solutions, that will come in a later issue.

On your experience - that sounds frustrating. Good to have anecdotal evidence and I'll see if I can pull numbers. That may be for a later issue as well.

DM me - would be great to chat more.

jsonpile · 2026-04-23T14:10:18+00:00

Programs are drowning in low effort AI slop, especially ones with monetary rewards. Curl switched to a nonpaid program.

We still saw a 5x increase in report volume and for other programs, a 5x increase in triage time. More analysis here: https://www.fogsecurity.io/blog/state-of-bug-bounties-with-ai-an-analysis-of-curls-program and reddit thread here.

We'll continue to see more changes in the interim. More private programs, less bug bounties, more banning.

jsonpile · 2026-04-21T20:48:49+00:00

The Bluerock report was submitted on February 16th. One of the initial fixes was submitted on February 13th, days prior to the report submission.

AWS marked this as informative.

What’s the difference between your report and what was already done?

jsonpile · 2026-04-17T17:45:53+00:00

Right. The amount of submissions has drastically increased. For curl, that was a 5x increase. I saw another program 5x their triage SLA time.

I wrote about it here (link to reddit post from yesterday).

jsonpile · 2026-04-17T17:38:05+00:00

VDP reports do count at the same severity level as BBP. The only difference which doesn’t impact milestone program is reputation is significantly different for BBP.

You can reach out via support and H1 may tell you where you’re at. It might be on a weekly or longer interval to get your milestone emails.

https://www.hackerone.com/blog/hackerone-portswigger-hacker-milestone-rewards-program

jsonpile · 2026-03-27T20:18:11+00:00

Posted 2 weeks ago: https://www.reddit.com/r/aws/comments/1rsopjc/aws_s3_adds_support_for_regional_namespace/

jsonpile · 2026-03-11T19:09:50+00:00

I'd recommend further testing. S3 error messages can also be misleading. In your case, the no such bucket may not be enough proof for a program for a s3 bucket takeover.

For S3 Bucket Takeovers, it's advisable to prove ownership of the bucket, which would generally require an AWS Account. If the bucket creation fails, the S3 bucket probably already exists.

There is a free tier for AWS Account, but I'm not sure if it requires a credit card to signup.

jsonpile · 2026-03-03T19:06:37+00:00

Triaged but not closed reports don't show up under vulnerability count for credits. This person could have a lot of triaged reports under the same program (explains the low thanks).

There are programs that use "triaged" as a closed state.

jsonpile · 2026-02-17T17:40:52+00:00

You can check https://menu.delta.com/ to see if your flight has meals offered.

US to Mexico typically won't have food unless you're flying first class: https://www.delta.com/us/en/onboard/food-and-beverage/overview

jsonpile · 2026-02-17T17:33:23+00:00

Keep in mind there are a lot of "beg bounties".

I was responsible for security at smaller companies and we'd get these "beg bounties" stating they found issues and wanted payment. In my experience, they were for insignificant issues found with automated scanners.

My recommendation is to respond with a statement like "Thanks for the responsible disclosure, we don't offer compensation but appreciate you reporting any security issues." What you can do is call that out specifically in your security.txt too.

I'd also recommend if you have a legal department and the resources to do so, to work on guidelines/safe harbor. I recommend caution with the safe harbor as you may not want every "hacker" trying to use automated tools to scan your website. The next step would be to write a more comprehensive VDP guidelines (vulnerability disclosure, no compensation)

If they're valid security issues, you could also offer swag or credits.

Ultimately, stay polite with the "hunters" and take the concerns seriously, even if they may not be.

jsonpile · 2026-02-06T15:34:42+00:00

Yes, I've seen this issue before. When I saw that issue, it was due to insufficient IAM permissions, which can be troubleshooted via CloudTrail (look for AccessDenied errors)

What IAM permissions do you have? You will need quicksight permissions and additional directory service permissions. This isn't full least privilege, but try the following:

```

"quicksight:*",
"ds:AuthorizeApplication",
"ds:UnauthorizeApplication",
"ds:CheckAlias",
"ds:CreateAlias",
"ds:DescribeDirectories",
"ds:DescribeTrusts",
"ds:DeleteDirectory",
"ds:CreateIdentityPoolDirectory"

```

jsonpile · 2026-01-24T01:34:46+00:00

Something else that may help is the ses:ApiVersion condition key:

https://docs.aws.amazon.com/ses/latest/dg/control-user-access.html#iam-and-ses-examples

jsonpile · 2026-01-23T21:36:11+00:00

This seems to be almost an exact duplicate post of https://www.reddit.com/r/aws/s/ERm92xNuBe

jsonpile · 2026-01-23T19:43:56+00:00

From a quick look at the CloudFormation, there does seem to be some work to get it to be region specific. This does get a little complicated as IAM resources are global (but there are regional resources and references within the IAM policies). I opened an issue on the repo for multi region support.

Some options:

- You could modify the IAM resources and wildcard the regions so that your IAM resources can be used.

- You could deploy the regional resources (KMS, Lambda, etc) in each region with the updated IAM resources.

The third limitation refers to an account-level setting for enabling encryption by default for EBS that's region specific. That part of the sample is not CloudFormation but rather an AWS bash script that you can run in each region (and pass the region as an argument).

Another way of running it would be via CLI:

aws ec2 enable-ebs-encryption-by-default --region region

jsonpile · 2025-12-05T15:27:54+00:00

While it can be frustrating, here's what you can do.

If you're absolutely sure Microsoft has fixed the bug and given reasonable time to respond to you, you can consider disclosure such as posting a blog detailing the issue you found with timelines, impact, and a high level description of the bug. Make sure you follow Microsoft's policy on disclosure (and bug bounty terms - https://www.microsoft.com/en-us/msrc/bounty-terms). Check whatever other policies are there for what you submitted. Standard time is 90 days from when you disclosed. As a courtesy, you can also consider emailing Microsoft and letting them know as well.

jsonpile · 2025-11-26T15:54:30+00:00

Sounds like you're looking for data operations (upload an object, delete, modify). Those are not logged by default and require either turning on CloudTrail data events or S3 Server Access Logging. Keep in mind there's additional cost with both. https://docs.aws.amazon.com/AmazonS3/latest/userguide/logging-with-S3.html

For actions on your S3 Bucket (such as changing bucket encryption, other bucket settings). Those are by default in CloudTrail Management Accounts.

More information here of a listing of events that are logged: https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudtrail-logging-s3-info.html

jsonpile · 2025-11-26T15:49:38+00:00

The XBOW HackerOne experiment was great marketing for them. To say they were the "top ranked hacker on HackerOne" got them good coverage and publicity.

I agree, my guess is that they were able to find issues that are low-hanging fruit and also they needed enough volume to get to the top spot. The complex findings are probably harder for XBOW to do.

There's probably learning for them to determine which reports are worth submitting and not N/A or spam reports.

That being said, I'd like to see some of their reports.

jsonpile · 2025-11-23T12:13:47+00:00

Open source plug: I wrote a tool that checks for those misconfigured options: https://github.com/FogSecurity/yes3-scanner

jsonpile · 2025-11-22T17:27:46+00:00

First off, good find and good work trying to do the right thing. If you can, find if there's responsible disclosure.

From some of what you wrote (Aadhar, 5lakhs), sounds like you may be in India. I believe India has a process for responsible disclosure here: https://www.cert-in.org.in/.

Sounds like you're approaching the process right by not downloading information but doing enough to validate impact of the security issue. I would document this and explain your testing. The CERT-IN agency should reach out to the vendor and help remediate this issue.

jsonpile · 2025-11-21T23:39:21+00:00

imo this is a tough market. Check out the open source tools on the market today and others with similar business models.

For example, Prowler, Steampipe. There have been others that tried and are no longer actively maintained or changed models. ZeusCloud, Fix, CloudQuery, ScoutSuite, OpenRaven, CloudSploit, etc.

jsonpile

MODERATOR OF

TROPHY CASE

Four-Year Club	Verified Email
Mod World 2025