What Happened
On April 28, 2026, a threat actor using the handle Crypt0nymz, previously linked to NullSec Philippines and Fawkes Pilipinas, publicly posted on Facebook addressing a private school in Rosario, Batangas. The post stated:
"Greetings! [school name], I found a security hole on your website that's exposing student info—names, enrollment, sections, and more. I'm not sharing this publicly because it could attract child predators. Just giving you a heads-up so your team can fix it before someone else stumbles on it. This is pretty urgent—leaving it open could put students in danger."
The post was framed in responsible-disclosure language but was made publicly via social media rather than through a private channel, and the actor included screenshots that themselves displayed portions of the affected portal. The post closed with the hashtag #crypt0nymz and greetz to CyberFr0st, Zeus, Lei\$, 0xTerror, 0xSeve, X10N, Nostra & Friends, B3RT, NSC, Ch4nc3ll0rx.1337, and special greetz to Fawkes Pilipinas and Nullsec Philippines — the same constellation of handles credited in earlier breach claims tracked on this site.
What the Screenshots Showed
Three screenshots accompanied the disclosure. Together they appear to show a logged-in administrative view of the school's information system rather than a public-facing student portal:
1. "All Payments" — Student List with Scheme
A scrollable list of student records showing, for each row:
- School year and quarter (e.g., `2025-2026` and `2026-2027 :: 1st Quarter`)
- Year level and program/strand (`GRADE 12 ACAD STEM`, `GRADE 12 ACAD HUMSS`, `GRADE 12 (Night) TVL HE`)
- Section / shift designation (Day vs. Night)
- Student surnames (specific surnames withheld here to protect the affected students)
- Payment status (e.g., `PAID`)
The first names and other identifying fields were partially redacted by the poster with red strike-through, but full surnames, year level, strand, and section were left visible. The visible left-hand navigation showed "DASHBOARD" and "ALL PAYMENTS" menu items — consistent with a staff/admin console rather than a student self-service portal.
2. Admissions / Assessment Dashboard
An aggregate dashboard showing live counts of admissions activity (pending, approved, rejected, and duplicate applications, broken out for new vs. returning students) and assessment activity (assessed students and assessed-with-payment students, broken out by gender). Specific figures are withheld here because the precise counts could be used to fingerprint the institution against public enrollment data.
3. Students Per Level / Per Section breakdowns
Per-year-level and per-section enrollment breakdowns covering nursery through Grade 12, including section names. Specific counts and section labels are withheld here for the same reason — the per-level numbers in particular are small enough that publishing them could identify the school.
The presence of nursery, kindergarten, and elementary-grade data in the same console means minors as young as 3–4 years old are in scope — which is the basis for the actor's "child predators" framing.
What Is and Isn't Confirmed
Confirmed from the screenshots themselves:
- A web-based administrative interface containing student-level records and aggregate enrollment data appears reachable in a way the threat actor was able to view and screenshot
- The exposed data includes at minimum: surnames, year level, academic track/strand, section, school year/quarter, and payment status, plus aggregate admission and assessment counts broken down by gender
- The data covers all year levels from nursery through Grade 12, including minors
Not confirmed:
- The exact vulnerability class (unauthenticated admin endpoint, IDOR, default credentials, exposed staging environment, leaked/weak admin credentials, etc.) — the actor did not describe the technical mechanism
- Whether the actor accessed only the records visible in the screenshots or has bulk-extracted the full dataset
- Whether full first names, addresses, contact numbers, parent/guardian information, or financial details (beyond payment status) are reachable from the same interface
- Whether the exposure has been remediated since the disclosure
- Whether the school has notified the National Privacy Commission (NPC)
This entry is sourced solely from the threat actor's social-media post and is therefore tracked as investigating pending independent confirmation. The school name has been redacted in public display.
Why This Disclosure Pattern Is Concerning
The disclosure follows a recurring pattern documented elsewhere on this site (see the Tagum private school breach and the public college in Batangas City breach, both involving overlapping NullSec Philippines / Fawkes Pilipinas handles):
- 1.A threat actor publicly posts a "heads-up" framed as responsible disclosure
- 2.Screenshots are included that themselves leak some of the very data the post claims to be protecting
- 3.The school is named publicly before any private notification or remediation window
- 4.No CVE, no advisory, no bug-bounty channel — the disclosure is on social media where it is immediately visible to other actors who may exploit the same flaw
Even where the discloser's stated intent is benign, the public posting of a live vulnerability with identifying screenshots materially increases short-term risk: any reader can attempt to reach the same interface before the school has had a chance to respond.
Recommended Actions for the Institution
Within the first hour:
- 1.Take the affected portal offline until the exposure is identified and contained. A maintenance page is preferable to leaving an exposed admin interface reachable
- 2.Preserve evidence — capture full server logs (web, application, database, authentication) before they age out of retention. Snapshot the current state of the system
- 3.Force a session and credential reset on every administrator and staff account that has access to the affected console
- 4.Block bulk-export and external-IP access to admin endpoints at the firewall / reverse proxy until a full review is complete
Within 72 hours (Data Privacy Act notification window):
- 1.Notify the National Privacy Commission (NPC) — under RA 10173, a personal data breach involving sensitive personal information of minors must be reported within 72 hours of discovery, regardless of whether the breach is "confirmed"
- 2.Begin drafting parent and student notifications — even if scope is still being assessed, prepare templated notifications so they can go out promptly when scope is known
- 3.Engage an external incident-response or DPO consultancy if internal capacity is limited — Philippine schools handling minors' data should not assess scope alone
Within one week:
- 1.Identify the root cause — common causes for an admin dashboard being reachable to an outsider include: (a) the dashboard route was not behind authentication, (b) authentication existed but session cookies could be forged or guessed, (c) admin credentials were weak, default, or leaked, (d) a development/staging copy of the system was deployed publicly, (e) an IDOR allowed a low-privilege user to view admin pages
- 2.Audit every other portal the school operates for the same class of flaw — the same developer or template often produces the same misconfiguration across multiple sites
- 3.Implement multi-factor authentication on all administrative accounts — this is the single highest-leverage control against credential-based intrusion
How to Prevent This Pattern
- 1.Authentication on every non-public route — admin dashboards, "all payments" views, and any page that displays student-level records must require authenticated, role-restricted sessions
- 2.Defense in depth — combine authentication with IP allow-listing for staff networks/VPN, MFA, and short session lifetimes
- 3.Separate environments — never expose staging, development, or test deployments of the student information system to the public internet
- 4.Data minimization in the UI — admin dashboards should not display more student PII than the role requires; bulk lists should be paginated and gated behind explicit search rather than rendered by default
- 5.Monitoring and alerting — log admin-page access and alert on anomalies (unusual IPs, off-hours access, large result-set fetches)
- 6.A documented disclosure channel — a published `security.txt` or a clearly advertised security contact gives genuine researchers a private route, reducing the share of disclosures that happen on social media
Context
The institution involved is a private K-12 and senior high school in Rosario, Batangas (CALABARZON). Because the affected console contains records for nursery, kindergarten, and elementary-age children alongside senior high students, the privacy harm and child-safety considerations are heightened relative to a college-only system.
Crypt0nymz has previously been credited in an earlier breach claim against a private school in Tagum City (March 4, 2026) and named in the greetz of multiple Fawkes Pilipinas / NullSec Philippines defacements and breaches tracked on this site. While the April 28 post is framed in disclosure-style language, the actor's prior history is relevant context for any institution evaluating the credibility and scope of the claim.
Shared-Platform Observation (Common SIS Vendor — Actor-Confirmed)
The same threat actor publicly stated in a separate May 1, 2026 post addressing a Catholic K-12 institution in San Juan, Batangas that "your school's website developer is the same one who worked on the [Rosario, Batangas school] website" — explicitly naming this institution as the developer-twin. That moves the shared-vendor question from "inferred from UI similarity" to claimed by the party with hands-on access to both systems.
In follow-up comments on that San Juan, Batangas post, the actor went further and stated "I actually have access to most of them already" in response to a community member who listed approximately eight sister institutions in the same organizational network (with this institution and the San Juan, Batangas institution marked as already disclosed). The full follow-up exchange — including the actor's separate claim that "none of the data was exfiltrated" — is documented in the San Juan, Batangas entry's follow-up comments section. That places this institution inside a named cluster of roughly eight schools the actor claims are reachable under the same vulnerability class, which is the appropriate unit of analysis going forward.
Independently, the screenshots in this disclosure share near-identical UI structure with screenshots from a separate claim against a Christian K-12 school in Imus City, Cavite posted on May 1, 2026, and with the San Juan, Batangas screenshots themselves. Common UI elements across all three affected consoles include:
- The same left-rail layout with a school logo, school name, DASHBOARD, and ALL PAYMENTS menu items
- The same top bar showing a school code, an academic-year and quarter label, and Menu / Reports controls
- The same per-student "Student List w/ Scheme" view, including identical field layout for assessment history, personal information, and a fee/discount breakdown
- The same admission and assessment dashboard layout, including the identical gender-broken-out "Assessed With Payment" treatment
This strongly suggests the affected institutions are running the same off-the-shelf or same-developer student information system (SIS), rather than independent custom builds. If that observation holds, this is materially a supply-chain incident: a single vulnerability or default-credential class in one shared platform can reach every school running it, regardless of each school's own security practices.
Implications if confirmed:
- 1.Other Philippine K-12 institutions running the same SIS are likely exposed to the same vulnerability, even if they have not yet been targeted publicly
- 2.The fix must be made at the vendor level — patching a single school's deployment will not protect the others
- 3.The vendor itself has a Data Privacy Act exposure as a personal-information processor, and the National Privacy Commission may have jurisdiction over the vendor in addition to the schools
- 4.A coordinated disclosure to the vendor is more effective than school-by-school remediation; affected institutions should compare notes and approach the vendor jointly
Independent confirmation of the shared-vendor hypothesis (e.g., a common URL pattern, common HTML/JS fingerprints, a vendor name visible in page source or HTTP headers) is needed before this can be treated as confirmed; the observation is included here because it materially changes the risk profile and the appropriate remediation path.