Post cover image

July 28, 2026

I Reported a Bug in Our Code, But My Senior Dev Got All the Credit

A Cybersecurity Fresher’s Honest Story About Credit Theft, Silence, and Learning to Speak Up

By Vijay Kumar Gupta

12 min read

A Cybersecurity Fresher's Honest Story About Credit Theft, Silence, and Learning to Speak Up

I still remember the exact moment I found that vulnerability. It was a Tuesday afternoon, somewhere around 3:30 PM, and I was three weeks into my first job as a cybersecurity fresher. I wasn't even supposed to be looking at that part of the codebase. I was just poking around, trying to understand how our internal application handled user sessions, because that's what freshers do. We poke around. We ask "why does this work this way?" way too many times a day.

And then I saw it.

An authentication bypass. A small, quiet, almost embarrassing flaw in how session tokens were being validated. Nothing dramatic. No alarms. No red screen. Just a logic gap that, if exploited, could let someone access another user's session without proper verification.

My heart actually skipped a beat. I remember sitting there, staring at my screen, feeling this strange mix of excitement and disbelief. Did I really just find that? Me? The fresher who still gets confused between IDS and IPS in casual conversation sometimes?

I want to tell you this story properly, because I think a lot of freshers in cybersecurity go through something like this at some point. Not exactly the same situation, but something close. You do good work, real work, and then somehow, someone else ends up wearing the credit for it. This is my story of how that happened to me, how I handled it, what I learned, and what actually changed afterward.

The Excitement Before The Storm

Let me back up a little. When I joined this company, I was fresh out of my cybersecurity certification program, buzzing with energy, and honestly a little scared too. Imposter syndrome hits hard when you're the "new security person" surrounded by developers who've been writing code for years.

My role wasn't glamorous. I was mostly doing vulnerability scans, reviewing logs, helping with basic penetration testing tasks under supervision, and learning the internal systems. Nothing high stakes. Nothing that would put my name on anything important.

So when I found that authentication flaw, it felt like a big deal to me. Like, genuinely big. This wasn't something a scanner flagged automatically. I found it manually, by reading through the session handling logic and noticing that a particular validation check was being skipped under certain conditions.

I did what any responsible fresher would do. I didn't panic. I didn't try to fix it myself, because that wasn't my place yet, and honestly, I didn't fully trust my own judgment at that stage. I documented everything carefully. I wrote a clear, detailed report explaining the vulnerability, how it could be exploited, what the potential impact was, and I sent it to my senior developer along with our team lead on Slack.

I was proud of that message. I remember rereading it three times before hitting send, making sure it sounded professional and not like I was overreacting.

The Reply That Changed Everything

My senior dev replied within ten minutes. "Good catch, let me verify this and take it to the team."

I remember smiling at my screen. Validation. That's all I wanted at that point. Just a little sign that I wasn't wasting everyone's time, that my instincts were actually developing into something useful.

For the next two days, nothing happened. No follow-up. No update. I assumed he was busy verifying it, maybe coordinating a fix, maybe looping in other stakeholders. That's normal, right? Things take time in a company, especially when security issues need to go through proper channels.

Then came the weekly team sync.

Our engineering manager opened the meeting by praising the team for "identifying and quickly patching a critical authentication vulnerability before it could be exploited." Everyone clapped. I remember feeling proud for a second, thinking, "That's my bug, that's my finding."

Then my senior dev spoke.

He explained, in detail, how he had "discovered an inconsistency in the session validation logic while reviewing the authentication module" and how he "flagged it immediately and worked on a fix." He walked through the technical details, the same details I had written in my report two days earlier. Almost word for word.

My name wasn't mentioned. Not once.

The Moment It Actually Sank In

I sat there in that meeting, camera off, completely frozen. My chest felt tight. Not because I wanted applause or recognition for the sake of ego, but because this was the first real, tangible proof of my skills as a cybersecurity fresher, and it was being handed to someone else in real time, in front of the entire team, in front of leadership.

I kept waiting for someone to say, "Wait, didn't the new fresher find this?" Nobody did. Because nobody else knew. Only he and I had that Slack conversation, and he clearly wasn't planning on correcting the narrative.

After the meeting ended, I just sat there staring at my laptop screen for a solid five minutes. I felt this weird combination of anger, embarrassment, and self-doubt all mixing together. Was I overreacting? Maybe he genuinely found it independently too? Maybe it was a coincidence?

I went back and reread my original Slack message and his reply. No, there was no coincidence here. He literally said "let me verify this," referring directly to what I sent him. There was a timestamp. There was a paper trail. This wasn't me imagining things.

That night, I didn't sleep well. I kept replaying the meeting in my head, questioning whether I should say something or just let it go and move on, because after all, I was still new, still finding my footing, and confrontation felt like a massive risk to my career.

Why Credit Theft Hits Different for Freshers

I think it's important to pause here and talk about why this situation feels so much heavier when you're a fresher, especially in a field like cybersecurity.

As a fresher, you don't have a track record yet. You don't have five years of proven wins behind you. Every small achievement is a brick in the foundation of your professional identity. When someone takes that brick away, it's not just annoying, it genuinely threatens how people perceive your competence, your value, and your future opportunities.

In cybersecurity specifically, finding vulnerabilities is one of the few concrete, undeniable ways a fresher can prove their skills early on. It's not like you're leading a big project or managing a team yet. You're proving yourself one finding, one report, one careful observation at a time.

So when that gets stolen, even quietly, even without dramatic confrontation, it stings on a much deeper level. It makes you question whether hard work and diligence even matter if someone senior can just repackage your findings as their own without consequence.

I also want to be honest about something else. Part of me wondered if this happened because I was new, because I was quiet in meetings, because I hadn't yet built a reputation that made people think twice before taking credit from me. That thought made me angrier than the actual incident itself.

Deciding Whether to Say Something

For two full days, I genuinely debated staying silent.

The arguments for staying silent were loud in my head. He's senior to me. He has influence. Confrontation could make things awkward or even damage my probation period. Maybe it's not worth the risk. Maybe I should just let this one go and focus on finding more bugs, building a stronger portfolio of evidence over time.

But there was one thought that kept pulling me back. If I stayed silent this time, what message was I sending, not just to him, but to myself? That it's okay for my work to be taken as long as the person taking it is senior enough? That my silence is the cost of being new?

That didn't sit right with me.

I also thought about it from a slightly more strategic angle. In cybersecurity, trust and credibility are everything. If this pattern continued and went unaddressed, it wouldn't just cost me one moment of recognition. It could shape how my contributions were perceived long term, potentially affecting future promotions, project assignments, or even how much responsibility I'd be trusted with.

So I made a decision. I wasn't going to create a dramatic scene. I wasn't going to publicly call him out in a meeting or send an angry email. But I was going to address it, calmly, professionally, and directly.

How I Actually Handled It

I want to walk you through exactly what I did, step by step, because I think the "how" matters just as much as the "why" in situations like this.

Step One: I Gathered My Evidence First

Before saying anything to anyone, I went back through my Slack messages and screenshots of my original bug report, timestamps included. I wanted facts, not feelings, to be the foundation of whatever conversation happened next. Emotions fade, get dismissed, or get labeled as "sensitivity." Timestamps don't.

Step Two: I Requested a One-on-One, Not a Group Confrontation

I messaged my senior dev directly and asked if we could hop on a quick call, just the two of us. I didn't want to embarrass him publicly, and honestly, I didn't want to burn a bridge either. I still had to work with this person daily. My goal wasn't revenge. My goal was correction and clarity going forward.

Step Three: I Led With Curiosity, Not Accusation

When we got on the call, I didn't open with "You stole my work." That would have put him immediately on the defensive and probably ruined any chance of a productive conversation.

Instead, I said something like, "Hey, I wanted to check in about the session validation bug from the sync meeting. I noticed the walkthrough matched pretty closely with what I originally flagged to you on Slack. I just wanted to understand how that got presented the way it did."

Calm. Direct. Fact based. No yelling, no sarcasm, no aggression.

Step Four: I Let the Silence Do Some Work

There was an awkward pause after I said that. A long one. I didn't rush to fill it with reassurance or backtrack on what I'd said. I just waited.

He eventually said something along the lines of, "Oh, I mean, I did verify it and work on the actual fix, so I kind of just explained the whole process as one thing."

That response told me everything. He wasn't denying that the discovery was mine. He was just rationalizing why he presented it as entirely his own.

Step Five: I Stated What I Needed, Clearly

I told him, calmly, that I understood he did the verification and the fix, and I genuinely appreciated that part of the work. But I also said that the original discovery was mine, and it mattered to me that this gets acknowledged, especially since it was still early in my time at the company and this kind of recognition actually impacts how my growth gets evaluated.

I specifically asked if he could send a quick follow-up message in our team channel acknowledging that I had flagged the original issue, just so the record was accurate.

The Uncomfortable Silence After

He agreed, somewhat reluctantly, saying he'd "mention it." For the next day, nothing happened. No message. No acknowledgment. I started second guessing whether I'd been too passive, whether I should have pushed harder in that conversation.

So I did something that felt scary at the time, but in hindsight was probably the smartest move I made in this entire situation.

I messaged our team lead directly, not to complain or escalate dramatically, but to simply clarify the record. I kept it short and professional. Something like, "Hey, just wanted to mention that the session validation issue from last week's sync was actually something I originally flagged during my review of the auth module. Wanted to make sure that's noted for my own tracking and growth conversations."

No accusations. No mention of my senior dev's name in a negative light. Just quiet, factual clarity.

Our team lead responded almost immediately, thanking me for the clarification and saying she'd note it for the sprint report and my performance notes.

That single message changed the entire trajectory of the situation.

What Changed After That

I wish I could tell you that everything became perfect and rosy after this, but that's not realistic, and I don't want to sugarcoat this story for the sake of a nice ending.

Here's what actually changed, honestly and in detail.

My senior dev became noticeably more careful around me. Not cold, not hostile, but definitely more cautious about how he referenced findings or credited work in meetings going forward. A few weeks later, during another sync, he actually mentioned my name directly when referencing a different issue I had flagged, unprompted. I don't know if that was guilt, awareness, or just him recalibrating how he operates around freshers now. Probably a mix of all three.

Our team lead started paying closer attention to attribution in general. After my message, she began asking more specific questions during syncs, like "Who originally identified this?" before jumping into technical walkthroughs. I noticed other junior folks on the team seemed to benefit from this shift too, not just me.

I became noticeably more confident in documenting my work. This whole experience taught me something crucial early in my cybersecurity career: document everything, always, with timestamps, without exception. Not because I expect people to steal credit constantly, but because clarity protects everyone, including the person who might genuinely misremember details later.

I stopped being afraid of uncomfortable conversations. This was probably the biggest internal shift. Before this incident, I associated "standing up for myself" with conflict, drama, and burned bridges. This experience taught me that calm, fact based, professional pushback doesn't have to be dramatic. It can be quiet, respectful, and still incredibly effective.

My relationship with my senior dev actually improved, oddly enough. We had an honest conversation a few weeks later, off the record, over coffee. He admitted that in his previous team, credit sharing wasn't really a norm, and he hadn't thought carefully about how his explanation in that meeting came across. I don't think he was maliciously trying to steal my work. I think he was just used to operating in an environment where individual contribution mattering separately from "team wins" wasn't emphasized.

That conversation mattered a lot to me, because it reminded me that not every instance of credit theft comes from a place of malice. Sometimes it comes from carelessness, old habits, or just not thinking about how their words land on someone newer, someone still building their professional identity from scratch.

What I'd Tell Any Cybersecurity Fresher Going Through This

If you're reading this because something similar happened to you, I want to say a few things directly to you.

First, your feelings about this are valid. It's not "just office politics" or something to brush off casually. Early career recognition genuinely shapes trajectories, confidence, and opportunities. It's okay to feel upset about it.

Second, document everything. From day one. Every bug report, every finding, every message where you flag something important. Timestamps are your best friend in situations like this. Not because you're expecting betrayal constantly, but because clarity benefits everyone involved.

Third, address it calmly, privately, and with facts first. Don't go in swinging with accusations. Lead with curiosity, state the facts, and clearly express what you need going forward. Most people respond better to calm clarity than aggressive confrontation.

Fourth, if the private conversation doesn't lead anywhere, it's okay to escalate quietly to someone who can help correct the record, like a team lead or manager. This isn't tattling. This is protecting your professional growth and your future opportunities.

Fifth, understand that standing up for yourself doesn't have to mean burning bridges. My relationship with my senior dev actually became stronger after this, not weaker, because I handled it with respect instead of resentment.

And finally, keep finding those bugs. Keep documenting. Keep growing. One uncomfortable meeting, one instance of stolen credit, doesn't define your entire career. It's just one moment in a much longer journey, and how you respond to it says a lot more about your professional maturity than the incident itself ever will.

Closing Thoughts

Looking back now, months later, I honestly don't feel bitter about this experience anymore. It taught me lessons about documentation, communication, and self-advocacy that I probably wouldn't have learned as deeply any other way.

Being a cybersecurity fresher means constantly proving yourself in small, quiet moments, moments that often go unnoticed unless you make sure they're noticed properly. That authentication bug wasn't just a technical finding for me. It became a turning point in how I understood my own worth, my own voice, and my own responsibility to protect my professional identity, even when it feels uncomfortable to do so.

If there's one thing I want you to take away from this story, it's this: finding the vulnerability was important, sure, but finding my voice afterward mattered even more.

Before You Go

If this article helped you think differently or gave you something practical to try, drop a "YES" in the comments. I genuinely read them, and they shape what I build and write next.

If you believe more people should see content like this, a clap and follow really helps. It supports independent creators and helps this work reach the right audience.

Thank you for taking the time to read till the end.

A Personal Note from Vijay Kumar Gupta

Hey, I'm Vijay Kumar Gupta.

I'm the Founder of EINITIAL24 and Digital GitHub, where I work on building practical tools, writing ebooks, and sharing real-world knowledge around technology, cybersecurity, automation, and digital growth.

I also run the In-Public Community on Discord, a space where builders, developers, and learners openly share ideas, experiments, and lessons — without fake hype or gatekeeping.

Beyond writing, I host a podcast on YouTube, where I talk about tech, startups, money, tools, and the realities behind building in public. I also write a regular newsletter on LinkedIn, sharing insights, learnings, and behind-the-scenes experiences that don't always make it into public posts.

You'll often find me:

Everything I share is based on hands-on experience — what worked, what failed, and what I learned along the way. No sponsors, no shortcuts, just consistent effort to help others learn faster by avoiding the mistakes I already made.

If you'd like to support this work:

  • Follow me across platforms where I share regularly
  • Join the community and newsletter to stay connected
  • And if this post helped you, clap, follow the writer, and share it with someone who might benefit

More tools, more stories, and more lessons coming soon. 🚀