Het Patel

@networkshard

India

Inventyv Software Services Pvt. Ltd.

I'm a Junior Cybersecurity Engineer working across penetration testing, vulnerability validation, security research, and defensive engineering. I care about findings that can be reproduced, systems that can be inspected, and remediation that holds up in practice.

My work is Linux-first and hands-on: I test web applications and infrastructure, review evidence closely, and turn repeated security workflows into understandable tools.

Skills & Tools

Penetration Testing · VAPT · Red Teaming · Vulnerability Assessment · Security Research · Ethical Hacking · Burp Suite · Nmap · Metasploit · Kali Linux · Wireshark · Python · Docker · Bash · Linux

GitHub ↗Download CV ↓

How I work

I prefer to learn from observable behaviour: reproduce the issue, preserve the evidence, test the boundary conditions, and make the result useful to the people responsible for fixing it. When a workflow repeats, I look for a way to make it safer and easier to inspect.

That approach runs through my Shard projects. In my writing, I also document the operational lessons behind the tools—including deploying an SSH honeypot and checking a dashboard against its underlying data.

Experience

In my professional work, I apply that same emphasis on verification, clear reporting, and practical remediation across production infrastructure and security assessments.

Inventyv Software Services Pvt. Ltd.

Junior Cybersecurity Engineer

Dec 2025 — Present

Ahmedabad, Gujarat

Monitor live logs and firewall rules across production infrastructure.
Audit all internal products for vulnerabilities and enforce security quality standards.
Collaborated with development teams to remediate vulnerabilities and improve secure coding practices.
Participated in internal security assessments and knowledge-sharing sessions.

Hacker4Help

VAPT & Cybersecurity Researcher — Intern

Apr 2025 — Jun 2025

Anand, Gujarat

Performed Vulnerability Assessment and Penetration Testing across 25+ websites and reported findings to stakeholders.
Researched emerging security threats and gained hands-on experience with automated VAPT tooling.
Assisted with content delivery, training material, and learner support.

Hall of Fame

NASA

Vulnerability Disclosure Policy (VDP)

Letter of Recognition — May 2026

View letter →

CERT-IN

Indian Computer Emergency Response Team

Hall of Fame — September & October 2025

View on CERT-IN →

Zyte

Responsible Disclosure Program

Security Researcher — Hall of Fame

View on Zyte →

CVEs

My security research includes work associated with the published advisories below. I present each issue in the scope documented by the vendor advisory, without implying that publication is a sole-discovery claim.

CVE ID: CVE-2026-35478
Score: 8.3/10

Arbitrary API Token Creation

InvenTree Security Advisory

Any authenticated InvenTree user can create a valid API token attributed to any other user in the system — including administrators and superusers — by supplying the target's user ID in the user field of a POST /api/user/tokens/ request. The returned token is immediately usable for full API authentication as the target user, from any network location, with no further interaction required.

View advisory on GitHub →

CVE ID: CVE-2026-41234
Score: 7.6/10

BIND Zone File Injection via TXT Record

Froxlor Security Advisory

The DomainZones.add API endpoint fails to sanitize newline characters in TXT record content, so an authenticated customer with DNS editing enabled can break out of the record line in generated BIND zone files. This allows injecting arbitrary BIND directives and DNS records — including $INCLUDE to read world-readable files, spoofed A/MX/CNAME records for subdomain takeover or email interception, and malformed content that takes the zone offline.

View advisory on GitHub →

CVE ID: CVE-2026-52793
Score: 8.1/10

API Authentication Bypasses 2FA

Froxlor Security Advisory

Froxlor's API authentication (FroxlorRPC::validateAuth) does not enforce Two-Factor Authentication. When a user enables 2FA, the web UI correctly requires a TOTP code — but the API accepts requests authenticated with only an API key and secret, issuing no TOTP challenge. An attacker who obtains a leaked API key+secret for a 2FA-protected account has full access to all API operations without providing a second factor.

View advisory on GitHub →

Certifications

CRTA

Certified Red Team Analyst

Cyberwarfare

Writing here

I use this site to write through security research, tooling, and lessons from running systems in the open. The archive is small by design and grows when I have evidence or a process worth sharing.

Page views

—

Blog Posts

Since

2025