👤 𝙄𝙣𝙩𝙧𝙤𝙙𝙪𝙘𝙩𝙞𝙤𝙣

Hello everyone, My name is Fathi Akhdan Dzaky. I'm a high school student (Grade 11) and a cybersecurity enthusiast passionate about security research and responsible disclosure. I spend a lot of my free time studying web security, understanding various types of vulnerabilities, and practicing ethical hacking to understand how systems can be secured against potential threats.

This is my first public security write-up, where I share my experiences with vulnerabilities I discovered during my security research. The goal is to raise awareness about security issues and demonstrate how simple mistakes—like exposed credentials—can lead to serious security risks.

I hope this article can also be a useful learning experience for others interested in cybersecurity and responsible disclosure practices.

🔎 𝘾𝙝𝙧𝙤𝙣𝙤𝙡𝙤𝙜𝙮 𝙤𝙛 𝘿𝙞𝙨𝙘𝙤𝙫𝙚𝙧𝙮 On Wednesday, February 18, 2026 (18/2/2026), I was conducting my usual security research activities. The goal wasn't anything special—simply the process of exploring and testing the attack surface (attack surface mapping) of various publicly available systems.

As part of the reconnaissance process, I also search public repositories to identify potentially exposed configuration files.

One common approach is to search for .env files in public repositories, as these files often store sensitive credentials such as API keys, tokens, passwords, or databases.

The search query I use to find exposed .env files is:

/[A-Za-z0–9-_]+\.target\.com\/+/ language:Dotenv

This is where things start to get interesting.

I found login credentials that appeared valid and related to CSIRT's internal systems. At first, I thought they might be dummy data or old, inactive credentials.

However, in security research, assumptions should never replace verification. To ensure its validity, I attempted authentication on the CSIRT Portal.

The results were quite surprising. The login process was successful! without any issues, with a few concerning conditions:

• No Multi-Factor Authentication (MFA)
• No IP restrictions
• No suspicious login activity notifications

After successfully logging in, I discovered that the account had the highest level of access to the system's internal dashboard. The account had Editor access level.

🔐 𝘼𝙘𝙘𝙚𝙨𝙨 𝙏𝙝𝙖𝙩 𝘾𝙖𝙣 𝘽𝙚 𝘿𝙤𝙣𝙚 Once inside the system, I performed limited verification to understand the impact of this vulnerability. This verification was performed without making any permanent changes to the system.

Some of the capabilities of this account include:

• Creating new users
• Changing user roles
• Editing system configurations
• Uploading files
• Accessing critical administrative features
• CRUD (Create, Read, Update, Delete) operations on several system components

At this point, it's clear that this isn't just a simple credential exposure. It's a combination of:

• Exposed Credentials
• Over-Privileged Access
• Administrative Control

If these credentials are misused by irresponsible parties, the potential impacts are quite serious, including:

• System takeover
• Data manipulation
• Uploading malicious files, such as webshells/backdoors
• Service disruption
• Web defacement
• Full account takeover

🔥 𝙎𝙚𝙫𝙚𝙧𝙞𝙩𝙮 𝙇𝙚𝙫𝙚𝙡 Based on the impact analysis and ease of exploitation, I categorize this vulnerability as: CVSS 9.8 — Critical

Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The reasons for this assessment are:

• The vulnerability is accessible over the network
• It does not require user interaction
• It does not require additional authentication
• It has a high impact on Confidentiality, Integrity, and Availability

🛡️ 𝙍𝙚𝙨𝙥𝙤𝙣𝙨𝙞𝙗𝙡𝙚 𝘿𝙞𝙨𝙘𝙡𝙤𝙨𝙪𝙧𝙚

During the verification process, I did not perform any further exploits. The following were not performed during the research process:

• No data downloaded
• No system configuration changes were made
• No permanent users were created
• No malicious files were uploaded
• No webshells or backdoors were inserted
• Etc.

🐞 𝙍𝙤𝙤𝙩 𝘾𝙖𝙪𝙨𝙚

The root cause of this vulnerability stems from login credentials being exposed in a public repository, allowing unauthorized parties to access internal systems.

Furthermore, the system appears to have overly broad access rights for certain accounts, magnifying the impact of a leaked credential.

🧩 𝙄𝙢𝙥𝙤𝙧𝙩𝙖𝙣𝙩 𝙇𝙚𝙨𝙨𝙤𝙣𝙨

Several lessons can be learned from this case:

• Secret exposure remains a common security issue
• Many internal systems have over-privileged access
• Credential hygiene is often neglected
• Secret leak monitoring should be automated

Sometimes, the biggest threat isn't a complex exploit or a zero-day. It's credentials accidentally left in the wrong place.

Security isn't about finding vulnerabilities to abuse. It's about finding vulnerabilities before the wrong people find them.

— Fathi Akhdan Dzaky