I am a curious and self-directed second-year engineering student at Sapthagiri University, specializing in AI & Data Science.
My interests lie in understanding the inner workings of complex systems, from philosophy to technical infrastructure.
I'm an independent security researcher with multiple CERT-In acknowledged responsible disclosures — spanning a mobile OEM, a multi-institution ERP vendor, and an admissions-platform vendor — built on top of a general interest in pattern recognition, vulnerability research, and secure/privacy-enhancing systems.
Books that stuck with me: Norwegian Wood by Haruki Murakami, The Stranger by Albert Camus, and The Metamorphosis by Franz Kafka.
I also spend a lot of time on the Collatz Conjecture — enough to have built my own notation for exploring it, which you can see below.
A file vault with no server or backend of its own — "no core." Files are compressed and encrypted entirely client-side, using a compressed-encryption approach that converts them to .bin, so only the person holding the key can ever decrypt them. The ciphertext itself is stored as plain text on a public paste service, which acts purely as dumb, opaque storage — visible to anyone as noise, meaningless without the key. A separate edit-key, held only by the owner, is required to modify or delete a stored file.
Systems ProgrammingC
Mini Shell (C)
A minimal Unix shell built from scratch
A small Unix shell written in C to better understand Unix process creation and inter-process communication. It currently supports executing commands and simple two-command pipelines using fork(), execvp(), pipe(), dup2() and waitpid(), with additional shell features planned as the project evolves.
MUNI-DISPATCH: Municipal Hazard & Utility Outage Dispatcher
Problem Statement PS-CIV-04 — built end-to-end in a single buildathon sitting
A civic-tech dispatch system built with a team at a buildathon hosted at Sapthagiri NPS University, under a hard time limit, then pitched live to the judges. Citizens report geotagged infrastructure hazards (electrical, water main, open sewer, gas pipeline, roadway/structural) by sector and urgency; duplicate reports in the same sector are automatically detected and merged into the existing ticket. PIN-protected municipal crews acknowledge, dispatch, verify on-site, and resolve each ticket through an atomic status pipeline, with every transition written to an audit log.
Built and deployed with a team: Zuveriya, Vedanth, Yuvaraj, and myself — backend, database design, and deployment/hosting were all done live within the buildathon's time constraint.
[ read stack & security details ]
Stack
Flask + Gunicorn backend, PostgreSQL (Neon) for storage, a vanilla-JS frontend with a Leaflet/OpenStreetMap map (falling back to an SVG sector grid offline). Deployed and hosted on Render within the buildathon window.
Security Notes
Crew AuthConstant-time PIN check, lockout after 10 wrong tries/10 min
Citizen PrivacyContact details only visible to signed-in crews
Input HandlingAll user text escaped; photo links restricted to http(s); CSP enforced
Abuse MitigationRate-limited reports; one confirmation per network per ticket
ConcurrencyDuplicate checks run under a per-category DB lock
Status flow is a strict state machine — REPORTED → ACKNOWLEDGED → DISPATCHED → ON_SITE_VERIFIED → RESOLVED — with each transition only valid from the correct previous state.
A small Flask tool for evaluating password strength and breach exposure
A university coursework project built in Python and Flask that scores password strength and checks breach risk, with a full project report. Scoped and small by design, but a useful first hands-on pass at applied security tooling before the larger disclosure work below.
Lockscreen Authentication Bypass — Vivo iQOO Z9s Pro 5G
In April 2025, I identified an authentication bypass affecting the lock-screen widget feature on Vivo's iQOO Z9s Pro 5G. The flaw allowed unrestricted internet browsing from a locked device — without a PIN, password, or biometric. I reported it both to India's Computer Emergency Response Team (CERT-In, internal case reference CERTIn-96182825 — not a publicly searchable ID; see the correspondence excerpts below) and directly to Vivo's security team, who independently confirmed the vulnerability in writing. Vivo shipped a fix in Lockscreen Poster v7.7.0.10, and CERT-In confirmed the resolution in January 2026 — handled end-to-end through responsible disclosure, with no public proof-of-concept released before the patch.
[ read full details ]
Technical Overview
The issue, classified as CWE-287 (Improper Authentication), sat in the Lockscreen Poster feature on Vivo iQOO Z9s Pro 5G — a feature designed to surface curated content on the lock screen without a full unlock. Under certain configurations, interacting with that in-feature content could route into a full mobile browser session, effectively exposing unrestricted internet access from a device that was still locked — no credentials, encryption, or OS-level protection was broken; the gap was in how a convenience feature was scoped relative to the lock state. In keeping with responsible-disclosure norms, and because a patch is now in wide release, I've intentionally left the exact interaction sequence out of this summary.
Impact Assessment
SeverityHigh
Attack ComplexityLow
PrerequisitesPhysical access to a locked device
AffectedVivo iQOO Z9s Pro 5G (Lockscreen Poster)
StatusPatched
Discovery & Disclosure Timeline
Apr 20, 2025Vulnerability identified on Vivo iQOO Z9s Pro 5G (Lockscreen Poster).
Apr 25, 2025Formally reported to CERT-In. Internal case reference: CERTIn-96182825.
Apr 26, 2025Reported directly to Vivo's security team.
May 21, 2025Vivo's security team confirmed the vulnerability in writing and began coordinating a fix internally.
Jan 19, 2026CERT-In confirmed Vivo's fix, shipped in Lockscreen Poster v7.7.0.10+.
"We have preliminarily confirmed the vulnerability and are communicating with the relevant teams about details and repair plans."
"Vivo has informed CERT-In that the patched version addressing the reported vulnerability has been fully deployed…"
Correspondence (redacted excerpts)
Screenshots of the actual case correspondence, cropped to the message content. Two individually named recipients on the Vivo thread have been redacted for their privacy; nothing else has been altered. Exploitation details remain withheld in line with responsible-disclosure norms.
CERT-In — report registered Apr 25, 2025Vivo Security Team — preliminary confirmation May 21, 2025CERT-In — fix confirmed Jan 19, 2026
Affected users should update the Lockscreen Poster app to the latest version. Happy to discuss the responsible-disclosure process in more depth — reach out at vishnuvardhan3965@gmail.com.
In July 2026, I identified an unauthenticated IDOR (Insecure Direct Object Reference) vulnerability in an image-retrieval handler used by UniRP, an ERP platform built by Bloomfield Innovations Private Limited, exposing student and faculty photos at Sapthagiri NPS University (SNPSU). The same pattern was reproducible, without authentication, across at least ten other institutional domains in multiple countries — all running the same vendor platform. Reported to CERT-In (Ref: CERTIn-42684126), to Bloomfield Innovations directly, and to Kenya's KE-CIRT/CC for the one affected institution there. A CVE request has been submitted via MITRE's CNA-LR process. As of this writing the vendor has not confirmed a fix, so this write-up deliberately stays high-level — no endpoint name, parameter, or reproduction detail is given below, and the affected institutions are not named beyond SNPSU.
[ read full details ]
Technical Overview
An image-retrieval handler in the vendor's ERP platform accepted a record identifier with no authentication or session requirement, returning a student's or faculty member's stored photo directly in the response. Because the same handler and parameter pattern were present, unmodified, across every institutional deployment checked, this was a platform-level flaw rather than a misconfiguration at any single institution. No path traversal or server-side data exposure beyond the intended image responses was confirmed, and only the minimum verification needed to establish the pattern was performed — no bulk extraction, no data retention. Given the vendor has not yet confirmed remediation, exact endpoint and parameter details are withheld here.
Impact Assessment
SeverityHigh
Attack ComplexityLow
Authentication RequiredNone
Data ExposedStudent/faculty photographs
Confirmed InstancesSNPSU + 10 other institutional domains, multiple countries
Vendor ResponseAcknowledged, fix unconfirmed
Current StatusCVE request submitted (MITRE CNA-LR)
Discovery, Reporting & Vendor Response
Jul 1, 2026Reported to CERT-In; registered under Ref: CERTIn-42684126. A video PoC with an active timestamp was provided on request.
Jul 18, 2026Confirmed the identical pattern reproducible, unauthenticated, across ten further institutional domains sharing the same ERP vendor — confirming a platform-level issue.
Jul 20, 2026Direct outreach sent to Bloomfield Innovations, citing the CERT-In reference and multi-institution scope. No acknowledgment received.
Aug 14, 2026CERT-In follow-up answered within 41 minutes, but with a generic template — no specific remediation detail. Vulnerability still unpatched at this point.
Deprioritized CERT-In as the primary channel (kept as a paper-trail record) and opened two parallel tracks: a formal vendor deadline letter, and an independent CVE request.
Sep 4, 2026Vendor response deadline set in a formal second-notice letter passed with no reply via email or LinkedIn.
Sep 7, 2026Moved to the fallback tracks: an independent CVE request, and direct notification to one further affected institution's national CERT (Kenya's KE-CIRT/CC, which acknowledged with ticket KE-CIRT/CC #2010508).
A CVE request for this issue was drafted and submitted via MITRE's CNA-LR process, scoped separately from an unrelated, later admissions-platform disclosure.
Bloomfield Innovations subsequently replied requesting a proof-of-concept, and branding referencing the vendor was removed from some, but not all, affected client portals. The underlying vulnerability itself remains unconfirmed as fixed.
This one is still active with the vendor and CERT-In, so I'm intentionally not publishing more than the above until a fix is confirmed. Happy to discuss the responsible-disclosure process in more depth — reach out at vishnuvardhan3965@gmail.com.
Between September and October 2026, I identified and reported a multi-stage, fully unauthenticated vulnerability chain in IonAdmission, the admission-management product built by IonIdea, confirmed on two separate university deployments: Sapthagiri NPS University (SNPSU) and MIT Academy of Engineering (MITAOE). An identical codebase, identical footer, and identical version string on both instances confirmed this as a systemic product flaw rather than a one-off misconfiguration. I reported it to IonIdea directly and to CERT-In as a case distinct from an earlier, separate disclosure. Neither has acknowledged the report. Both affected portals have since gone offline, one of them replaced entirely by a new system — so the write-up below documents the chain structurally, the reporting timeline, and the silence, without publishing anything that would still work against a live target.
[ read full details ]
Technical Overview
The product chained four weaknesses into a single unauthenticated path from "anonymous visitor" to "edit any applicant's record." An enumerable identifier on a certificate-retrieval request could be stepped through with no session or login at all. The response for a given identifier mapped directly onto that applicant's stored document, and the storage location itself carried no access control of its own. Because the retrieved document contained the applicant's government ID number and date of birth — and because those two values were, by the product's own design, that applicant's login credentials — an attacker could move straight from an anonymous document fetch to a fully authenticated session as that applicant, with no guessing involved. From there, a single path segment in the application's own URL scheme was the only thing separating a read-only record view from a fully editable one. Exact endpoint names, request parameters, and path structure are intentionally withheld below — the chain only reproduces against a live instance of the exact product build in question, and every confirmed instance has since been taken offline.
Impact Assessment
SeverityCritical
Attack ComplexityLow
Authentication RequiredNone
Data ExposedAadhaar/ID number, DOB, financial & admission documents
Current StatusBoth instances offline / unacknowledged
The Chain
Click a step to read it. Structure only — no endpoint names, parameters, or paths, and nothing here reproduces against a live target.
A certificate-retrieval request accepted an applicant identifier with no login or session required. Stepping that identifier up or down returned a different applicant's record on every request — no rate limiting, no authentication, no barrier at all.
The response for a given identifier mapped directly onto that applicant's stored document. The storage location itself carried no access control of its own — no token, no session, nothing tying retrieval back to a login.
The retrieved document contained the applicant's government ID number and date of birth, both fully visible — no further access needed to read them.
Those two values were also, by the product's own design, that applicant's login credentials. An anonymous document fetch became a fully authenticated session with no guessing involved.
Once authenticated, a single path segment in the application's own URL scheme — view versus edit — was the only thing standing between reading a record and rewriting it: identity details, contact information, and financial fields, all editable with no further check in between.
Discovery, Reporting & Silence
Sep 7, 2026Discovered while independently re-checking whether an earlier, unrelated disclosure had been patched — found this separate vulnerability chain in SNPSU's admission portal instead.
Sep 2026Confirmed an identical vulnerability chain on a second institution's portal (MITAOE), same codebase and version string — a vendor-wide issue, not a single misconfiguration.
Sep 2026SNPSU runs two similarly-named domains — a singular one actually operated by Meritto, and the plural one hosting the vulnerable portal — and a one-letter mix-up between them led to an initial report being sent to the wrong vendor; their security team responded promptly, denied ownership, and the mix-up was corrected.
Sep 2026Correct vendor confirmed — IonIdea, makers of "IonAdmission." Report sent directly to their security contact.
Sep 2026Also escalated in person at SNPSU; routed through several non-technical staff before reaching the institution's designated technical contact, who was left a written technical notice.
Sep 2026Filed with CERT-In as a case distinct from the earlier disclosure (Ref: CERTIn-42684126). A status request was answered citing the old reference number rather than registering a new case.
Oct 5, 2026Formal written report sent to IonIdea, with a 5-business-day acknowledgment request and a 15-30 day remediation window.
Oct 11, 2026Follow-up sent to CERT-In requesting explicit confirmation this was logged as a distinct case. No response received.
Oct 12, 2026IonIdea's acknowledgment window lapsed with no response of any kind.
Oct 13, 2026Both portals showed partial changes (login disabled on one, 404 on the other), but the underlying document-storage endpoint was confirmed still live and unauthenticated — the lockout was cosmetic, not a fix.
SinceBoth instances are now fully unreachable. SNPSU has replaced its admission portal entirely with a new, differently-built system at a new address. No acknowledgment has been received from IonIdea or CERT-In at any point in this process.
Correspondence (cropped excerpts)
Screenshots of the actual sent/received correspondence, cropped to the message content only (browser and mail-client chrome removed). Every reply shown here is organizational — a vendor security team or CERT-In's incident desk — rather than a named individual, so nothing required name redaction.
Initial report sent (misattributed vendor) Oct 4, 2026Vendor denies ownership, identifies IonAdmission Oct 5, 2026Formal report sent to IonIdea Oct 5, 2026Follow-up — deadline lapsed, endpoint still live Oct 13, 2026CERT-In — requesting registration confirmation Sep 10, 2026CERT-In replies citing the old case reference Sep 10, 2026Clarifying this is a separate case Sep 10, 2026CERT-In follow-up — still unanswered Oct 11, 2026
I'm not pursuing a formal CVE for this one — there was never a vendor acknowledgment to anchor it to, and both confirmed instances are gone. This write-up, and the corresponding CERT-In thread, stand as the record. Happy to discuss the responsible-disclosure process in more depth, or how multi-tenant education software ends up repeating the same mistake across institutions — reach out at vishnuvardhan3965@gmail.com.
A personal notation for the Collatz conjecture, built around thinking of it as a branching structure rather than a single sequence. Every odd number sits at the base of a "rail" — repeated doubling — and a rail branches wherever (v-1)/3 lands on a whole number, spawning a new rail one level down. Instead of plotting that tree in 2D or 3D (where branches inevitably overlap), each step forward through a number's trajectory gets addressed by its position: nX_k for the rail a number starts on, nY_k for every branch after that. k is how many doublings that odd base sits below the next branch point. It's an independent exploration, not a peer-reviewed proof — a way of walking the sequence that surfaces structure a plain forward run hides.
Pick a range and generate each number's rail-and-branch notation client-side, right here in the browser.
View colf.py — Python reference implementation
def collatz_notation(n):
parts = []
first = True
while True:
divisions = 0
while n % 2 == 0:
n //= 2
divisions += 1
value = divisions + 1
if n == 1:
parts.append(f"1X{value}")
break
if first:
parts.append(f"{n}X{value}")
first = False
else:
parts.append(f"{n}Y{value}")
n = 3 * n + 1
return ", ".join(parts)
n = int(input("Enter a positive integer: "))
print(collatz_notation(n))
Interactive Step-Count Grapher
For each number in a range, this counts how many odd terms occur in its Collatz trajectory before reaching 1 — effectively how many branches of the notation above it takes — then plots the result. A quick way to see how erratic the sequence length gets even over small ranges.
def collatz_step_count(n):
"""Count the odd terms in n's Collatz trajectory, including the final 1."""
count = 0
while True:
while n % 2 == 0:
n //= 2
count += 1
if n == 1:
break
n = 3 * n + 1
return count
def generate_counts(start, end):
return [collatz_step_count(n) for n in range(start, end + 1)]
if __name__ == "__main__":
start = int(input("Start: "))
end = int(input("End: "))
counts = generate_counts(start, end)
print(",".join(str(c) for c in counts))
Security ResearchSandboxingWebAssembly
What a Sandbox Experiment Taught Me About Loader Patterns
[ read full research write-up ]
The RTEST experiment was a Python runtime that worked entirely client-side, in the browser, via WebAssembly (Pyodide) — no backend server involved at all. The idea was simple and, at the time, felt like a neat sandboxing exercise: gate the runtime behind a locally supplied key, and let the browser do all the work of deciding whether that key unlocks anything meaningful. An interesting idea that evolved into a more elaborate architecture than I expected.
I built the whole thing from scratch, without immediately realizing that the shape of what I'd made — an encrypted payload plus a key, decrypted and run entirely on the client, with the hosting side never seeing the plaintext — is also the standard architecture behind loader and dropper malware. That's not a coincidence of naming; it's a coincidence of goals. Anything that wants to hide its payload from static analysis or content moderation ends up with the same design, because "nobody but the key-holder can see what this does before it runs" is exactly the property such a mechanism needs. I arrived at the same shape honestly, from a sandboxing angle, and only later recognized the overlap. Whoever has the key unlocks the door — but only whoever made the key knows what's actually inside, and the moment you type the right key, you're trusting it blindly.
The actual flaw isn't who's running the code — it's that a "decrypt, then execute" pipeline with no validation step in between can't tell the difference between a wrong key producing garbage and a right key producing something malicious. Successful decryption isn't the same thing as trustworthy content, and treating it as the only gate for execution means the architecture has no way to ask "should this actually run?" at all.
That's the real lesson this project left me with. A security-conscious version of the same idea wouldn't execute decrypted output at all — it would treat it strictly as untrusted data, and if code execution is genuinely required, it would authenticate the payload (a signature check, not just "did decryption succeed") before anything runs. The live mechanism isn't part of this redesign — the value here isn't the mechanism itself, it's being able to point at exactly where the design goes wrong and why.
