It’s been a while since my last write-up, yet the break brought some valuable insights. Over the past few months, I’ve quietly stacked up few real-world security findings some subtle, some severe, and all of them overlooked in their own way. From bypassing regex-based protections to leaking full source code via exposed .git directories, this post is a compilation of bugs that quietly slipped through the cracks. This isn't just a report it's a post-mortem on what happens when "it should be secure" isn't good enough.

Finding 1: Vanishing Tasks & Locked Dashboards.

Imagine a critical task list that helps keep your security in check, things you’ve flagged to come back to later. Now, picture someone subtly making those tasks disappear, not just from their view, but from everyone’s view, permanently. While exploring a system’s security dashboard, I found that by tampering with task IDs, a malicious admin could silently hide all ignored security tasks across the entire platform. The twist? These tasks weren’t deleted or archived, they were just gone. Invisible from every admin’s view, with no option to recover or track them. No alerts, no errors, no logs. Just an empty UI and a dangerous illusion of no issues.

So, the application allows admin to either Ignore the task or Take action on it. While ignoring the task, the POST request was made as:

POST /api/security/dashboard-info/ignored-tasks/1 HTTP/2
Host: target.com
Content-Type: application/json
{"reason":"test"}

By injecting a crafted long numeric task ID (like 1111111111 or 000000000000000 )into the above request’s numeric value, the system would enter a broken modal state. This bug occurred due to a lack of proper validation on task identifiers, allowing malformed IDs to corrupt system behavior and UI state and worse: this corrupted state affected all users across the tenant, regardless of role. Simply reloading the /administration/security-dashboard endpoint from any other account led to the same frozen screen. The only fix? There was no UI-based recovery, no validation to block malformed IDs, and no graceful fallback. This vulnerability was triaged as medium severity due to its tenant‑wide impact on visibility and usability.

Finding 2: SVG File Upload to System-Wide DoS via Unsafe XML Parsing

Sometimes, a simple image upload can bring down a whole subsystem. While testing the customization options in the Card Management section of the application, I came across a feature that allowed users to upload SVG files for product branding logo. Nothing unusual until I decided to test what the parser does with extended XML features.

By crafting a minimal SVG file containing a harmless-looking <xi:include> directive (an XML feature for including external content), I triggered unexpected backend behavior. The system attempted to parse the embedded include path, leading to timeout and ultimately a 504 Gateway Timeout error.

At first, the issue appeared isolated, uploads failed, asset previews broke, and even basic navigation within the affected endpoint became inaccessible. Not just for my session, but for every legitimate user interacting with that part of the system. Yes, anyone attempting to access this specific endpoint for logo upload/update during the attack window would consistently receive a gateway error, resulting in a blank error page instead of the expected content. The affected window lasted for roughly one minute, during which every user hitting that specific endpoint experienced the same gateway errors and blank pages. This bug was accepted with a High severity rating of 8.6 due to its ability to cause system-wide denial of service affecting all users accessing the impacted endpoint.

Finding 3: Prometheus Metrics Exposure Through Case Manipulation Bypass

While exploring the application via recon, I came across something unusual. An endpoint “/metrics” that was meant to be off-limits, showing an access denied message, could surprisingly be accessed just by playing around with the letters in the URL.

By mixing uppercase and lowercase characters, I was able to view detailed system metrics that should have never been visible without proper permissions. This simple trick exposed backend information that could easily help someone understand how the system works under the hood. This issue was accepted with a Low severity rating since no highly sensitive information was disclosed, the focus remained solely on the access control bypass rather than exposure of critical data.

Finding 4: From Webhook Testing to Internal Port Scanning

While testing target’s webhook functionality, I discovered a Server-Side Request Forgery (SSRF) vulnerability that allowed me to interact with internal services and enumerate open ports by bypassing the standard localhost restrictions. Even after an initial patch, I was able to bypass the fix using a simple redirection technique, confirming that internal ports and services remained accessible through the vulnerable endpoint.

Initially, the common localhost addresses like 127.0.0.1 and localhost were properly blocked by the application. However, I was able to bypass this restriction by using alternate loopback IPs such as 127.1.1.1 and 127.0.1.1, which still resolve internally to the localhost, allowing me to enumerate internal services.

Although this issue was initially fixed by blocking these alternate loopback addresses, I was later able to bypass the protection again by using a redirection technique, hosting a simple redirect server on my machine that pointed back to the internal host. This allowed me to enumerate internal open ports and discover reachable paths by analyzing the server’s different error responses and timings. This vulnerability was triaged as Medium severity, and the report was rewarded with a double bounty in recognition of initial fix bypass.

Finding 5: Exposed .git Directory Leads to Complete Source Code Leakage

While testing this application, I stumbled upon a classic yet critical misconfiguration an exposed .git directory left accessible on the internet. This small oversight allowed me to retrieve the entire source code of the application using publicly available tools like git-dumper.

What started as a simple check for forgotten files quickly turned into full access to the codebase, highlighting how a single misstep in deployment can open the door to serious security risks.

The extracted repository was over 3 GB in size, containing the complete application codebase, internal configuration files, and potentially sensitive data. This finding clearly demonstrates how a single overlooked configuration can expose the heart of an application. The report was accepted as High severity due to the sensitive source code disclosure and full access to the application’s codebase.

In summary, each of these findings highlights how small oversights can lead to impactful vulnerabilities, some even surviving initial fixes. These reports not only earned acknowledgments and bounties but also served as a reminder of how continuous testing and validation are crucial for maintaining secure systems. If you’d like to stay updated on my future findings or just follow along with what I’m working on, feel free to connect with me on LinkedIn and Twitter, I’d be glad to have you there!