1.5 Years of VDP, 6 CVEs, and the Finding That Felt Different: Hacking the AWS

That number might look impressive.

But if you've spent any meaningful amount of time doing vulnerability research, you know that the number doesn't tell the story.

I've been doing Vulnerability Disclosure Programs for around 1.5 years.

In that time, I've had accepted reports, rejected reports, duplicates, severity disagreements, reports that took months to move, and countless hours spent staring at code trying to figure out whether something was actually exploitable.

Before this finding, I already had five CVEs under my name.

So when CVE-2026–85012 was assigned, the excitement wasn't simply:

"I got another CVE."

It was:

"I found a vulnerability in software published by AWS."

And that felt different.

AWS isn't just another organization on a bug bounty list.

It operates one of the world's largest cloud platforms, with an enormous ecosystem of services, applications, developers, and infrastructure depending on its technology.

And somewhere inside that ecosystem was a small piece of code that caught my attention.

A piece of code that eventually led to an OS command injection vulnerability in the Amazon CodeCatalyst Blueprints SDK.

This is the story of how I found it, what went wrong along the way, and, more importantly, what 1.5 years of vulnerability research has taught me.

The CVE

The vulnerability is now publicly tracked as:

CVE-2026–85012

Vulnerability: OS Command Injection CWE: CWE-78 CVSS 3.1: 8.0 High Affected package: @amazon-codecatalyst/blueprints.blueprint Fixed version: 0.3.156

AWS published a security bulletin for the issue and acknowledged my contribution through its coordinated vulnerability disclosure process.

You can read the official advisory here:

But the CVE itself is only the ending.

To understand why this finding mattered to me, we need to go back to where it started.

1.5 Years of VDP

When I started doing vulnerability disclosure, I had a very different idea of what vulnerability research looked like.

I thought finding vulnerabilities meant:

Find bug → submit report → get accepted.

Pretty straightforward.

It didn't take long to realize how wrong I was.

The reality was much closer to:

Find something interesting → investigate → reproduce → doubt yourself → investigate again → write the report → wait → answer questions → reproduce again → explain the impact → wait some more.

And sometimes the final answer is:

Duplicate.

Or:

Informative.

Or:

Not applicable.

And you start again.

Those experiences were probably more valuable to me than the accepted reports.

They taught me how to think.

They taught me that finding a suspicious piece of code isn't the same as finding a vulnerability.

They taught me that impact matters.

They taught me that reproduction matters.

And most importantly, they taught me to keep asking questions.

The Sixth CVE

While looking into Amazon CodeCatalyst Blueprints, I started looking at how project data was handled during resynthesis.

One particular file caught my attention:

.ownership-file

I wanted to understand how this file was processed and whether any of its values could influence sensitive operations.

As I followed the code, I found that data from the file could eventually reach a command execution function without sufficient validation.

That was the moment the investigation changed.

What initially looked like a configuration-related issue turned out to have security impact.

The next question was simple:

What could an attacker actually do with it?

That question led me deeper into the code and into the trust boundaries around the feature.

From Configuration to Command Execution

The interesting part of this vulnerability wasn't simply that a project file could contain user-controlled data.

The important question was what happened to that data afterward.

During my investigation, I found that a value associated with a local merge strategy could ultimately influence command execution.

That meant something that started as project data could cross a security boundary and reach a much more privileged operation.

At that point, I had enough evidence to believe I was looking at an OS command injection vulnerability.

But finding command execution is only part of the job.

I still needed to understand the environment in which that execution happened, who could influence it, what permissions were required, and what the actual security impact was.

That turned out to be just as important as finding the bug itself.

The Part Nobody Sees: Getting the Reproduction Right

One of the biggest lessons from this report wasn't actually the vulnerability.

It was reproduction.

My initial explanation around the location of the .ownership-file wasn't precise enough.

That created confusion during validation.

Instead of defending the original reproduction blindly, I went back to the source.

I traced the file discovery logic.

I traced the resynthesis behavior.

I re-evaluated what the application was actually reading.

And I corrected the reproduction path.

This was an important lesson for me.

When someone tells you that your reproduction doesn't work, there are two possibilities.

Maybe the vulnerability is wrong.

Or maybe your understanding of the reproduction is wrong.

Your job is to figure out which one.

If your reproduction fails, don't immediately abandon the vulnerability. First question your assumptions.

That mindset has helped me more than any single vulnerability technique.

Understanding the Trust Boundary

Once I understood the technical behavior, I started looking at the bigger question:

Who could actually reach this functionality?

This is where the vulnerability became more interesting from a security perspective.

A blueprint author already has significant control within the synthesis context.

But a contributor working with a project repository is a different trust level.

The security boundary exists because project contributors should not automatically gain the ability to execute arbitrary commands in the environment responsible for processing that project.

That distinction mattered when assessing the real impact.

It also helped explain why the final severity was different from my initial assessment.

From Critical to High

My initial assessment was CVSS 9.9 Critical.

The final AWS assessment was:

CVSS 3.1: 8.0 High

And honestly, that's okay.

The difference came down largely to the privileges required for exploitation and the interaction involved.

The attacker needs permission to commit to a repository in the project.

That matters.

Security severity isn't simply:

"Can I execute commands?"

It's also:

"__Who can reach the vulnerable functionality?"

"What privileges do they need?"

"Does another user or process need to trigger something?"

"What environment does the code execute in?"

"What could that environment access?"

These questions are a huge part of vulnerability research.

A strong report isn't one where you give yourself the highest possible CVSS score.

A strong report is one where your assessment can survive scrutiny.

When AWS Got Involved

Eventually, the report moved through the disclosure process and reached AWS VDP.

This was probably the point where the finding became particularly meaningful to me.

Not because AWS is somehow impossible to find vulnerabilities in.

But because working on software from an organization operating at this scale forces you to raise your own standards.

Your evidence needs to be good.

Your reasoning needs to be defensible.

Your reproduction needs to be understandable.

Your assumptions need to be challenged.

And your communication needs to be precise.

There was also a practical challenge.

Amazon CodeCatalyst stopped accepting new customers in November 2025, which meant I couldn't simply create a new CodeCatalyst environment and reproduce everything from scratch.

That made the validation process more complicated.

The vulnerable component itself was available as an open-source npm package, so I focused heavily on understanding and validating the behavior of that package and its surrounding code.

Eventually, the report was validated locally and escalated to AWS VDP for investigation.

That process taught me another important lesson:

Sometimes vulnerability research is as much about proving what you found as it is about finding it.

CVE-2026–85012

Eventually, the issue received a CVE assignment.

CVE-2026–85012.

AWS classified it as:

CWE-78: Improper Neutralization of Special Elements used in an OS Command

with a CVSS 3.1 score of 8.0 High.

The affected versions were fixed in:

0.3.156

The fix addressed the unsafe command execution behavior and introduced stronger validation around the relevant values.

And then I saw something that made the whole process feel real.

AWS publicly acknowledged me for the disclosure.

"We would like to thank Vaibhav Kubade for collaborating on this issue through the coordinated vulnerability disclosure process."

Seeing my name there was a moment I'll remember.

Not simply because my name appeared in a security bulletin.

But because it represented roughly 1.5 years of learning, failing, experimenting, reporting, improving, and doing it all over again.

Five CVEs Before This One

This is something I really want to emphasize.

CVE-2026–85012 is my sixth CVE.

So this article isn't about getting my first CVE.

It's about how different the sixth one felt.

Your first CVE proves something to you.

It proves that you can find a vulnerability, understand it, reproduce it, and communicate it well enough for someone else to take it seriously.

The next few start teaching you methodology.

You begin to notice patterns.

You start paying more attention to trust boundaries.

You start asking:

• Where does untrusted data enter?
• Where does it go afterward?
• Which component trusts it?
• Does it cross a privilege boundary?
• Can configuration influence code?
• Can data influence an operation it shouldn't?
• Does a lower-privileged user influence a higher-privileged process?

That shift in mindset is what I value most from the last 1.5 years.

To Everyone Trying to Get Their First CVE

This is the part I really wanted to write.

If you're currently doing VDP and haven't received a CVE:

Don't worry about the CVE.

Seriously.

I know that's easy to say after getting six of them.

But I genuinely believe it.

Focus on becoming good at understanding software.

Read source code.

Understand architectures.

Learn authentication.

Learn authorization.

Understand how applications communicate.

Understand how cloud services work.

Study how data moves through an application.

Learn to recognize trust boundaries.

And most importantly:

Follow the data.

If you see something like:

input → parser → object → helper → API

input → parser → object → helper → API

don't stop at the parser. Follow it. Understand what happens to that value next. Then next. Then next. The vulnerability might be several functions away from where the input first enters. That's often where the interesting bugs are hiding.

Your Rejected Reports Aren't Wasted

I've had reports that didn't go anywhere.

Everyone doing vulnerability research eventually does.

Some reports are duplicates.

Some aren't actually vulnerabilities.

Some don't have enough impact.

Some are technically correct but don't meet the program's requirements.

It can be frustrating.

Especially when you've spent hours or days on something.

But I've learned not to treat those reports as wasted effort.

Maybe you learned how to build a better PoC.

Maybe you learned how to reproduce something more reliably.

Maybe you learned that your threat model was wrong.

Maybe you learned how to explain impact more clearly.

Maybe you learned how to distinguish an interesting behavior from an actual security issue.

Those lessons accumulate.

You don't always see the value immediately.

Then one day you're looking at another piece of code and suddenly you recognize a pattern because you've already made that mistake before.

That's how researchers grow.

Don't Be Afraid to Be Wrong

One of the biggest changes in my mindset has been becoming comfortable with being wrong.

You investigate something.

You think you've found a vulnerability.

You test it.

It doesn't work.

Fine.

Figure out why.

Maybe you misunderstood the code.

Maybe you misunderstood the threat model.

Maybe there's another protection.

Maybe your reproduction is wrong.

Maybe the behavior isn't security-relevant.

Or maybe you've found something interesting but haven't reached the real impact yet.

Being wrong during research isn't failure.

Refusing to learn from being wrong is failure.

Every researcher gets things wrong.

The difference is what you do afterward.

The CVE Is the Result, Not the Goal

If I could go back 1.5 years and give myself one piece of advice, it would be:

Stop chasing the CVE. Chase the understanding.

Understand the system.

Understand the code.

Understand the trust model.

Understand the attack surface.

Understand what happens when assumptions break.

The CVE comes later.

Sometimes it doesn't come at all.

And that's okay.

Because even when a report gets rejected, you might walk away better than you were before you started investigating it.

That knowledge stays with you.

Why This Finding Felt Different

I've had five CVEs before this one.

So getting a sixth CVE wasn't something I had never experienced before.

What made this one different was the context.

I wasn't just looking at another application.

I was looking at software published by AWS.

I was digging through open-source code.

I found a security boundary that didn't behave the way I expected.

I had to prove the behavior.

I had to correct my own reproduction.

I had to explain the impact.

I had to deal with severity differences.

I had to deal with the practical limitations of reproducing a service that was no longer open to new customers.

And eventually, the issue became public.

That entire journey mattered more to me than the CVE number itself.

What's Next?

CVE-2026–85012 is one milestone.

It isn't the finish line.

There are still countless systems I don't understand.

Countless technologies I haven't learned.

Countless vulnerabilities I haven't found.

And probably a lot more reports that will end with:

"Informative." 😂

That's part of the game.

I'll keep learning.

I'll keep breaking things responsibly.

I'll keep reporting what I find.

And hopefully, I'll keep encouraging more people to start their own journey into vulnerability research.

Because 1.5 years ago, I was also just someone trying to figure this out.

I didn't know where the next accepted report would come from.

I didn't know how many reports would be rejected.

I didn't know how many times I'd have to go back and rethink an idea.

I just kept looking.

And eventually, things started clicking.

So if you're at the beginning right now:

Keep going.

Don't measure your progress only by CVEs.

Measure it by how much better you understand software than you did six months ago.

Measure it by the bugs you can recognize today that you couldn't recognize before.

Measure it by the mistakes you don't make anymore.

Because sometimes the difference between a researcher who finds vulnerabilities and one who doesn't isn't talent.

It's simply the willingness to keep looking a little longer.

Your next breakthrough might be one investigation away.

Final Note

Huge respect to the security teams and researchers who make coordinated vulnerability disclosure possible.

And to everyone who has ever helped a beginner understand a bug, reviewed a report, shared research, or simply said:

"Keep going."

Thank you.

You probably helped someone more than you realize.

CVE-2026–85012

OS Command Injection in Amazon CodeCatalyst Blueprints SDK

CWE-78

CVSS 3.1: 8.0 High

Fixed in 0.3.156

If you're a vulnerability researcher reading this and you're currently sitting on a pile of rejected reports, confusing bugs, unfinished investigations, and ideas you're not sure are vulnerabilities yet:

Keep digging.

That's where the journey actually starts.