A Christian school in Imus City, Cavite

What Happened

On May 1, 2026, a Facebook account using the name Nullsec Philippines publicly posted addressing a private K-12 institution by name. The post text read:

"Greetings, [school name]. Why don't you start prioritizing the security of all your data? I'm already getting sleepy. You might wanna check it out."

The post was signed with the hashtag #crypt0nymz and included greetz to CyberFr0st, Zeus, Lei\$, 0xTerror, 0xSeve, X10N, Nostra & Friends, B3RT, NSC, Ch4nc3ll0rx.1337, with special greetz to Fawkes Pilipinas and Crypt0nymz — the same constellation of handles credited in the private school in Rosario, Batangas claim, the state university in Nueva Vizcaya CAT claim, and earlier incidents tracked on this site.

What the Screenshots Show

The disclosure included multiple screenshots of a logged-in interface displaying the institution's logo and name in the sidebar, a left-hand navigation showing DASHBOARD and ALL PAYMENTS, and a top bar reading 2025-2026 :: 4th Quarter with Menu and Reports controls — consistent with a staff/administrator console rather than a student or parent self-service portal.

1. Per-student "Student List With Scheme" view

A detail page tied to an individual student record. Visible fields included:

• A student selector showing year (`2024-2025`), grade level (`Grade 10`), and a section label, followed by the student's full first, middle, and last name (specific values withheld here)
• An Assessment History sidebar showing a multi-year academic trajectory (e.g., `2023-2024 :: Grade 9`, `2024-2025 :: Grade 10`)
• Student's Personal Information: First Name, Middle Name, Last Name, Gender (the threat actor partially red-marked the first and last name fields in the screenshot, but the middle name was visible in plaintext)
• School Fees Breakdown: Tuition Fee, Miscellaneous Fees (two line items), Energy Fee, Computer Fee / Internet Fee, Registration Fee, Total School Fees, plus a Discount table (including an ESC discount line)

2. Coordinator / Subject-Teacher grade-posting roster

A table view listing, per row:

• Coordinator name
• Subject Teacher name
• Level / Section (covering Grade 4, 5, and 6 with section labels)
• Subject (Araling Panlipunan, Computer 20%, Mathematics, Christian Values)
• Teacher Posting Status (`POSTED` / `NOT POSTED`)
• Coordinator Posting Status

This view exposes staff-level information (which teachers are responsible for which sections, and which have completed grade submission) alongside section assignments. Specific staff names and section labels are withheld here.

3. Aggregate Admission and Assessment Dashboard

A dashboard with live counts:

• Admission Status (NEW Students): Pending, Approved (split across two payment stages), Duplicate, Rejected (split across two stages)
• Admission Status (OLD Students): Pending, Approved (with a footnote that Grade 12 is not included)
• Assessment Status (NEW Students): Assessed total, plus "Assessed With Payment" broken down by gender — male and female counts
• Assessment Status (OLD Students): same structure

Specific figures are withheld here because the precise counts could be used to fingerprint the institution against public enrollment data. From the visible aggregates, the affected dataset covers on the order of several hundred students spanning at least Grades 4 through 12, with elementary-grade data also surfaced through the per-section roster.

What Is and Isn't Confirmed

Visible from the screenshots themselves:

• A web-based administrative interface displaying the institution's branding, with an admin-style left navigation (Dashboard / All Payments) and a Reports control
• Per-student records including full names, gender, year level, section, multi-year assessment history, and full fee breakdowns with discount entitlements
• A staff-level roster mapping coordinators and subject teachers to specific sections and subjects, with grade-posting completion state
• Aggregate enrollment, admission, and assessment counts spanning new and returning students with gender-broken-out totals
• Coverage that includes minors

Not confirmed:

• The exact vulnerability class (unauthenticated admin endpoint, IDOR, default or leaked staff credentials, exposed staging environment, session compromise, 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 contact numbers, addresses, parent / guardian information, government IDs, or financial-instrument data 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 institution name has been redacted in public display, and the specific student, staff, and section names visible in the screenshots are not reproduced on this site.

Why This Is More Serious Than the Single-Account NVSU Claim

Unlike the single-account claim against the NVSU CAT portal — which showed only one applicant's view — the screenshots in this disclosure are consistent with administrative or staff-level access:

• The interface includes a Dashboard, an "All Payments" report, and a Reports control — features that no student or parent account should have
• Aggregate admission and assessment dashboards are visible — these are management views, not self-service views
• A coordinator / subject-teacher grade-posting roster is visible — this is a faculty-administration tool

If the access is in fact administrative rather than scoped to a single user, the exposure is not a single-record incident: it is a system-wide exposure of every student record reachable from that console, including minors, fee and discount data, and staff assignments.

Recommended Actions for the Institution

Within the first hour:

1. 1.Take the affected console offline until the exposure is identified and contained
2. 2.Preserve evidence — capture web, application, database, and authentication logs before they age out, and snapshot the current state of the system
3. 3.Force a session and credential reset on every administrative, coordinator, and faculty account with access to the affected console
4. 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. 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. 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. 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. 1.Identify the root cause — common causes include: (a) admin routes not gated by authentication, (b) authentication present but session cookies forgeable or guessable, (c) admin / faculty credentials weak, default, or leaked, (d) a development or staging copy deployed publicly, (e) an IDOR allowing low-privilege users to view admin pages
2. 2.Audit every other portal the school operates — admissions, enrollment, learning management, alumni — for the same class of flaw; the same developer or template often produces the same misconfiguration across multiple sites
3. 3.Implement multi-factor authentication on all administrative and faculty accounts — this is the single highest-leverage control against credential-based intrusion

How to Prevent This Pattern

1. 1.Authentication on every non-public route — admin dashboards, "All Payments" views, grade-posting rosters, and any page that displays student-level records must require authenticated, role-restricted sessions
2. 2.Defense in depth — combine authentication with IP allow-listing for staff networks/VPN, MFA, and short session lifetimes
3. 3.Separate environments — never expose staging, development, or test deployments of the student information system to the public internet
4. 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. 5.Monitoring and alerting — log admin-page access and alert on anomalies (unusual IPs, off-hours access, large result-set fetches)
6. 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 school operating a unified information system that covers admissions, fee assessment, grading, and enrollment management. Because the affected console contains records for minors alongside fee, discount, and staff-assignment data, the privacy-harm and child-safety considerations are heightened.

The May 1, 2026 post is the third disclosure in close succession from handles linked to Nullsec Philippines / Fawkes Pilipinas / Crypt0nymz that has been logged here, following the private school in Rosario, Batangas claim (April 28) and the state university in Nueva Vizcaya CAT claim (also May 1). The pattern — public Facebook post addressing the institution by name, screenshots that themselves leak portions of sensitive data, no private notification or remediation window — is consistent across all three.

Shared-Platform Observation (Common SIS Vendor — Actor-Confirmed Across Sister Schools)

In a separate May 1, 2026 post addressing a Catholic K-12 institution in San Juan, Batangas, the same threat actor explicitly stated that "your school's website developer is the same one who worked on the [Rosario, Batangas school] website" — confirming a shared SIS vendor between those two institutions. In follow-up comments on that same post the actor went further, stating "I actually have access to most of them already" in response to a community member who listed approximately eight institutions in a shared organizational network running the same SIS — and separately stated that "none of the data was exfiltrated" (a self-reported claim that does not relieve any affected institution of its incident-response or RA 10173 notification duties). The full follow-up exchange is documented in the San Juan, Batangas entry's follow-up comments section.

The eight-institution cluster the actor has access to belongs to a different organizational network than this Imus, Cavite institution, so this school is not part of that named cluster. However, the screenshots in this disclosure share near-identical UI structure with the screenshots from both confirmed-cluster institutions, strongly suggesting this institution is a customer of the same shared SIS vendor even though it does not belong to the same religious-school network. If that observation holds, the actor's "they're all the same vulnerability" framing extends to this deployment too, even without an explicit shared-developer call-out from the actor for this institution. 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. 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. 2.The fix must be made at the vendor level — patching a single school's deployment will not protect the others
3. 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. 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.