If you've read my last 3 articles, you probably have some idea what this one's gonna be about.

And that they weren't all that fictional, or hypothetical. Or AI generated.

Here's a fun fact:

The article — "Abuse of Gitlab.com Shared Runners for Denial-of-Service Activity" never existed. Gitlab never wrote it, but they should have.

What I didn't mention is that I spent about 2.5 months hunting on Gitlab's H1 program, found 10+ valid medium/high severity issues. 90% of them were mysteriously marked as informative.

Well, it's not that mysterious actually.

Different vulnerability types, severities, and a million excuses.

Gitlab didn't act alone though, they used a professional, 3rd party gaslighting service, HackerOne.

Sooner or later, I had to realize that they were both running a massive con.

And What Does It Pay?

Instead of running VDP (slave labor) like a honest corporation, they expect quality work for nothing in return.

But why 90% of reports instead of all 100%?

It's a classic bait and switch tactic where a company triages one vulnerability, giving false hope that maybe you'll get paid some day. Four months later it became painfully obvious — they were never going to pay me a $.

What about people that like doing free labor? The everyday heroes who sacrifice to make internet a safer place for ordinary civilians.

Corporation:

I'm offering you a real opportunity, VDP_SLaVe_X.

VDP_SLaVe_X:

To do what?

Corporation:

I don't usually share my business plan with you, but a moment has arrived that could allow the company to make enough money to expand to the next level. We could call this the critical moment. I'm inviting you, VDP_SLaVe_X, to be part of the team that pounces on this opportunity.

Looking at corporate profits … quickly glancing at VDP_SLaVe_X, Corporation:

You've been asking a lot about your performance review. Well, for starters I'm seeing a great improvement with regards to your overall focus and badge earning. Given complex problems you're developing a real ability to find clear, simple solutions. I'm also aware of your increased enthusiasm. It's great to see how your eyes light up when you're working on new ideas. I hope you'll be inspiring us with your innovative thinking for years to come.

VDP_SLaVe_X:

Thanks, man. I'm trying.

Corporation:

Which is why I'm promoting you to executive vice president of our vulnerability research division.

VDP_SLaVe_X:

What am I now?

Corporation:

You're an assistant.

VDP_SLaVe_X:

Does it come with a raise?

Corporation:

Absolutely.

VDP_SLaVe_X:

How much?

Corporation:

Pick a number.

VDP_SLaVe_X:

0$ for an RCE.

Corporation:

Agreed.

VDP_SLaVe_X:

What about more?

Corporation:

Well not now. We closed the deal.

VDP_SLaVe_X:

I could've gotten more couldn't I?

Corporation:

Absolutely.

Spoiler Alert: Don't hunt on VDP's or this might happen to you :(

Back To GitLab: About Compliance & SLA's

I've said it before, but it's worth repeating — GitLab powers some of the biggest names out there: Goldman Sachs, the U.S. military, Nvidia, and countless other multibillion-dollar firms.

It goes without saying - they expect top-tier security and transparency.

The Deadlines

Thirty days for high-severity vulnerabilities, ninety for medium, and one-hundred-eighty for low.

And a hundred years for "informative."

All Gitlab has to do is accurately rate severity and fix bugs in time. Seems simple enough, right?

But what if they got clever and started labeling 70%+ of all valid reports as "informative"? It would save millions in the short term — and no one would even notice or care. No accountability, no consequences.

But dismissing 70%+ of all valid reports — isn't that kinda illegal and fraud'ish? Leaving a mountain of unfixed security issues — isn't that gross negligence? What about time to remediate, CVSS and all of that?

If we dig deeper we can find something like:

We take compliance seriously

At GitLab, we know how much security, privacy and accessibility matters to our customers and stakeholders.

And

Why are vulnerability remediation SLAs important?

Remediation SLAs set reasonable expectations, based on the criticality of a vulnerability and expected impact, for how quickly GitLab users and customers can expect a security vulnerability to be mitigated. Vulnerabilities and the work required to address them require work to mitigate, and like all work, this must be prioritized. Severity and impact-based SLAs are the simplest way to prioritize this work whilst delivering the most positive impact to the security of our products, systems and in turn the security of our customers and users.

Translated from corporate:

"Goldman Sachs? More like Goldman can Sach deez nutz." — Gitlab

Vastaamo Case

What happens when standards get lower and lower?

Vastaamo was a Finnish private psychotherapy service provider founded in 2008.[1] On 21 October 2020, Vastaamo announced that its patient database had been hacked. Private information obtained by the perpetrators was used in an attempt to extort Vastaamo and, later, its clients.[2] The extorters demanded 40 bitcoins, roughly worth 450,000 euros at the time, and threatened to publish the records if the ransom was not paid. To add pressure to their demands, the extorters published hundreds of patient records a day on a Tor message board.

If Gitlab continued it's immaculate corporate strategy, some of their clients' clients could have joined Vastaamo in Valhalla.

Tragically, some individuals affected by the Vastaamo data breach died by suicide. During the trial of Aleksanteri Kivimäki, the perpetrator of the breach, lawyer Jenni Raiskio, representing victims, revealed that her firm had been contacted by people whose relatives had taken their own lives after their patient records were published online.

Near Universal DoS

Some of my reports were average, some quite interesting, and one of them was a DoS vulnerability who's exploit worked on 99% of Gitlab instances I tested on.

Before anyone says: "Hey, that's illegal, you have no right to do this. Also, highly illegal. Did I mention that it's very illegal?"

In normal scenarios, yes. This time? I got permission from both GitLab and H1.

And I didn't even get a permaban on H1. That's how I know they're ok with it.

The investigation is still pending, nearly a month after confession.

But isn't doing millions of $ in damages (2+ week DoS), attempted extortion/blackmail, etc. against H1 rules? Well, it's complicated.

The Pitiful State of HackerOne

H1 will ban you for being homophobic, or for no reason.

Very long investigation.

It's good that they're good people. Very forgiving.

Exploring Options

Before reporting to LE, Gitlab had to calculate whether it's worth it to inform their clients, LE, investors. Here's how badly they fked up.

Compare these 2 scenarios.

Option A:

An unreported DoS vulnerability caused this level of damage — Gitlab is partly at fault because they didn't invest enough in cybersecurity.

Option B:

1. A previously reported DoS vulnerability (7.5+ severity)
2. Marked as informative (fraud) (along with many other "informatives")
3. Not fixed for 4+ months (negligence)
4. Exploited using their own shared runners (50k+ free minutes — about 5K $) and they didn't notice for 2 weeks+ (more failures/negligence?)
5. Attacker starts sending veiled threats to their enterprise customers, after 12 hour+ "negotiation" with H1 support bot, Gitlab finally bans attacker

Option A is pretty bad, especially if many enterprise customers are targeted. Option B is 10x worse.

Failure, after failure that resulted in a catastrophe. If only there were ways to prevent it…

Remember, each time a program marks your critical/high/medium severity vulnerability as "Informative", their intent is to not only not pay you, but to also have unlimited fix deadline. This part is important, because they're also defrauding their own customers.

This is especially true for Gitlab.

I still don't know if it was a real person or H1 is so criminally stingy that they use AI support bots for cases like this. This is another massive failure, but not from Gitlab's side.

There are still many questions left unanswered —

Did they inform LE?

Did they inform their clients?

Did they tell the whole truth?

Nearly a month has passed by now.

If they didn't inform LE — that's collusion and even more potential legal issues. Either H1 or Gitlab could've/should've done that immediately.

Them not informing law enforcement reminds me of that one scene from that one movie.

Where applicable, HackerOne reserves the right to inform relevant authorities as is deemed necessary.

Either way, it was "killing 2 birds with 1 stone". Or incriminating both Gitlab and H1 with one report (#3118020).

HackerOne — By Criminals, For Criminals.

Gitlab didn't do a public blog post/writeup. No K-8 form either.

I thought that it was a material event? But it's not for me to decide. Either way, they had 4 business days to declare it, starting from September 22.

Whistleblower Sounds Nicer Than

Congratulations, you've reached the ending.

Did you know that sec.gov has a snit… I mean, whistleblower program? Any ra… Whistleblower can earn some cold, hard cash if they say something after seeing something.

an SEC enforcement action in which over $1 million in sanctions is ordered. The range for awards is between 10% and 30% of the money collected.

Please don't report. Because I could've just made all of this up. Everything could be fiction/AI generated bullshit. Either way, if you're not braindead, you should add 2 + 2.

Gitlab still owes me $30,000+ for my honest labor. These guys are real jerks!

Thanks for reading.