A Catholic K-12 institution in San Juan, Batangas

What Happened

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

"Greetings, [school name]. I noticed that your school's website developer is the same one who worked on the [other school name] website. It might be a good idea to talk to your developer and sort things out. If other schools are using the same developer, they're cooked. If someone finds out how to get in, good luck. Thank God I don't have any intent of leaking this data, as it contains children's info."

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 Rosario, Batangas claim (April 28), the Imus, Cavite claim (May 1), and the state university in Nueva Vizcaya CAT claim (May 1).

What Makes This Disclosure Different: Actor-Confirmed Shared-Vendor Claim

Unlike the previous claims in this batch — where a shared SIS vendor was an inference from UI similarity — the threat actor's own post explicitly names a different institution as sharing the same developer. That moves the supply-chain hypothesis from "likely based on UI" to "claimed by the party with hands-on access to both systems."

The actor's framing also includes a notable forward-looking warning: "If other schools are using the same developer, they're cooked." Read literally, this asserts that the same defect class is reachable on every customer of that developer — not just the two named institutions.

This is the most operationally important sentence the actor has posted across this batch. If accurate, it implies:

1. 1.At least two confirmed customers of the same SIS vendor are vulnerable to the same access vector
2. 2.Other unnamed customers of the same vendor are likely also vulnerable, even if they have not been publicly targeted
3. 3.The fix must be made at the vendor level — patching one school's deployment will not protect the others
4. 4.The vendor itself is the weak link, not the schools' individual security postures

Follow-up Comments: Actor Claims Access to Most of ~8 Sister Schools

Within roughly thirteen hours of the original post, the threat actor returned to the same comment thread and made two additional public statements that materially change the scope of the disclosure:

1. Stated no data exfiltration. The actor's first own-comment on the post read simply "None of the data was exfiltrated. -Crypt0nymz". This is an unverified claim from the threat actor and should be treated as such — admin-tier access to a live student information system is sufficient to read, copy, modify, or delete records regardless of whether bulk exfiltration occurred. From an incident-response standpoint the institution must still treat the dataset as having been viewed by an unauthorized party, must still preserve logs to determine what was actually accessed, and must still meet RA 10173 notification obligations.

2. Confirmed access to most of an enumerated list of sister schools. A separate Facebook user replied to the actor's comment asking whether this institution was a sister school of the private school in Rosario, Batangas, noting that "their UI looks very similar to each other" and that "there are 8 schools within their organization". The community member then listed the eight institutions by short-form abbreviation, marking two of them as already publicly disclosed:

```

DAZSMA

SRA

SJA

SJC (done)

A Catholic K-12 institution in San Juan, Batangas (done)

SSGM

HFA

OLFA

```

The threat actor responded:

"I actually have access to most of them already—I just haven't had the time to post them yet. They're all the same vulnerability, but thanks for the heads-up regardless! -Cryptonymz"

This is the first time the actor has put a concrete count on the scope of the supply-chain compromise. Read together with the original post, the actor is claiming:

• A specific, named cluster of approximately eight sister institutions runs the same SIS / website built by the same developer
• More than two of those institutions are already accessible to the actor under the same vulnerability class — bounded above by eight, and described by the actor as "most"
• The same vulnerability class works against every accessible deployment — i.e., this is not a one-off misconfiguration of a single school's instance, but a defect in the shared product or its default deployment posture

What This Means for the Other Sister Schools

The comment-thread expansion shifts the appropriate response posture from "two schools should patch and notify" to "the vendor and every customer in the cluster should treat themselves as actively compromised until proven otherwise." Specifically, for any institution that recognizes itself in the eight-abbreviation list above and has not yet been publicly named:

1. 1.Assume access already exists. The actor's own statement is "I actually have access to most of them already." Operate as though an unauthorized party already holds working credentials or a working unauthenticated path into the admin console
2. 2.Take the affected console offline immediately — a maintenance page is preferable to leaving a known-accessible admin interface reachable while remediation is scoped
3. 3.Force credential and session resets on every administrative, coordinator, and faculty account that touches the SIS, and rotate any shared service credentials the SIS uses
4. 4.Preserve logs now, before they age out — at minimum the past 30 days of web, application, database, and authentication logs
5. 5.Notify the National Privacy Commission (NPC) within 72 hours — the threshold for notification under RA 10173 is the existence of a personal data breach involving sensitive personal information (which a K-12 SIS holding minors' records meets), not the institution's certainty that exfiltration occurred. The actor's own no-exfiltration claim does not discharge the notification obligation
6. 6.Coordinate, do not silo. Sister schools running the same SIS are facing the same vendor-level defect; a joint approach to the vendor and a joint statement to families is materially more effective than each school responding alone

What the Screenshots Show

The disclosure included multiple screenshots of a logged-in interface explicitly labeled "Admin Dashboard" with the welcome message "Welcome to [institution name]" and the institution's logo and name in the sidebar. The left navigation showed DASHBOARD and ALL PAYMENTS menu items; the top bar showed a school code, an academic year, and a quarter label, along with Menu and Reports controls — the same layout pattern observed in the Rosario, Batangas and Imus, Cavite disclosures.

1. Admin Dashboard landing page

A landing page explicitly titled "Admin Dashboard" with a welcome banner naming the institution, plus widgets for Announcements, a localized notices section, and an embedded School Calendar. The breadcrumb showed "[institution short code] / Admin Dashboard" — confirming admin-tier access rather than a student or parent view.

2. Admission and Assessment Dashboard

An aggregate counts view showing:

• Assessment Status (All Students): an overall assessed total, an enrolled total, and a male/female breakdown
• Admission Status (NEW Students): Pending, Approved (split across two payment stages), Duplicate, Rejected (split across two stages) — the visible Approved-stage-2 count alone was several dozen students
• Admission Status (OLD Students): Pending (with hundreds of records, footnoted that Grade 12 is excluded) and Approved
• Assessment Status (NEW Students) and Assessment Status (OLD Students): Assessed totals plus "Assessed With Payment" with gender breakdown

Specific figures are withheld here because precise counts could be used to fingerprint the institution against public enrollment data. From the visible aggregates, the reachable dataset spans on the order of several hundred to a thousand student records.

3. "All Payments" — Student List With Scheme

A scrollable selector showing student records spanning multiple academic years (the visible entries included 2022-2023, 2023-2024, 2025-2026, and 2026-2027), with each entry showing year, level, surname, and payment status (`PAID`). The visible level for many entries was NURSERY, confirming that the dataset reaches children as young as 3-4 years old. Specific surnames and identifiers from the dropdown are withheld here.

4. Students Per Level / Per Section breakdowns

Per-level enrollment lists covering Grades 11 and 12 across multiple academic strands (ABM, STEM, HUMSS, HUMSS-ASSH, ICT/Computer Programming, HE) and per-section lists with section names. Specific section names and counts are withheld here because they could be used to fingerprint the institution.

What Is and Isn't Confirmed

Visible from the screenshots themselves:

• A web-based interface explicitly labeled "Admin Dashboard" with the institution's branding
• Multi-year student records (at least four academic years) reachable through a "Student List With Scheme" view, with surnames and payment status
• Aggregate admission and assessment dashboards covering both new and returning students with gender-broken-out totals
• Per-level and per-section enrollment data covering at minimum nursery through Grade 12
• Coverage that includes children as young as nursery age

Not confirmed:

• The exact vulnerability class — the actor did not describe the technical mechanism beyond naming the developer
• 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 full first names (beyond the surnames and partial first-name values visible in the dropdown) are reachable from the same interface
• The identity of the shared SIS vendor / developer (named in the actor's post but withheld here pending independent confirmation, to avoid amplifying an unconfirmed supply-chain claim)
• Whether the exposure has been remediated since the disclosure
• Whether either named 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.

Recommended Actions

For the named institution:

1. 1.Treat as an active incident — take the affected console offline, preserve logs, and force credential and session resets on every administrator and faculty account
2. 2.Notify the NPC within the 72-hour window — the dataset includes minors and triggers RA 10173 notification obligations regardless of whether the breach is "confirmed"
3. 3.Preserve evidence and engage external incident-response capacity if internal capacity is limited

For the shared-developer / SIS vendor (whoever they are):

1. 1.Treat the actor's claim as a credible vendor-level vulnerability report. Audit the codebase for the same defect class in every customer deployment
2. 2.Notify all affected school customers — even those not yet publicly named — and coordinate a synchronized patch and credential rotation
3. 3.Disclose to the NPC as a personal-information processor under RA 10173

For other schools running the same SIS:

1. 1.Identify whether your institution is a customer of the same vendor (signs include the same UI fingerprint described in the shared-platform observation on companion entries)
2. 2.Contact the vendor directly and request written confirmation of patch status before relying on continued operation
3. 3.As an interim control, consider IP-allowlisting the admin console to staff networks/VPN, forcing MFA on all administrative accounts, and reviewing access logs for unauthorized sessions over the past 30 days

How to Prevent This Pattern

The defensive recommendations from the Rosario, Batangas and Imus, Cavite entries apply here in full and are not repeated. The unique addition for this entry is vendor due diligence:

1. 1.Treat the SIS vendor as part of your attack surface. Every customer of a poorly-built SIS inherits that vendor's vulnerabilities, no matter how mature the school's own controls are
2. 2.Require a signed Data Processing Agreement (DPA) with any vendor handling student PII, including specific obligations on disclosure timelines and breach notification
3. 3.Ask vendors for evidence of security testing — recent third-party penetration tests, OWASP-aligned secure-coding practices, or at minimum a clear remediation track record
4. 4.Operate a multi-customer disclosure channel — schools running shared SaaS should have a way to communicate with each other when one is breached, since the same vector likely affects all of them

Context

The institution is a Catholic K-12 school in CALABARZON, with a unified information system covering admissions, fee assessment, and enrollment management spanning at least four academic years of records. The reachable dataset includes nursery-age children, which heightens the privacy-harm and child-safety considerations.

The actor's explicit naming of the shared developer makes this entry's most useful contribution to the public record the supply-chain framing: the right unit of analysis here is the vendor and its customer base, not any single school in isolation.