SchoolBreach.org
BreachesTrendsToolsLearnAbout
Free Security Check
Security Check
SchoolBreach.org

A public resource tracking data breaches in Philippine schools. Helping administrators protect student data through awareness, education, and free security tools.

© 2026 SchoolBreach.org · A community service by OceanEd

Navigate

  • Breaches
  • Trends
  • Tools
  • Learn
  • Methodology

Company

  • About
  • Privacy Policy
  • Terms of Service
  • Contact Us

Disclaimer: This tracker is maintained for educational and awareness purposes. Incidents are documented using threat intelligence monitoring, Philippine media reports, NPC filings, and responsible disclosures. Social media platforms are monitored for leads and are corroborated before publication or naming — never through active scanning or exploitation. Severity ratings and summaries are prepared with AI assistance and reviewed editorially. Full methodology →

Back to Breach Tracker
Database Leak
HighUnconfirmed

A state university in Mindanao

The name of this institution has been withheld pending verification of the source. This entry is based on an unconfirmed report.

On August 4, 2026, the Facebook account 'Nullsec Philippines,' signed by the persona 'Nostra,' publicly addressed a state university in Mindanao by name and published a link to a plain-text file said to contain extracted student email addresses. The post attached a screenshot of an HTTP interception proxy showing a single POST request to a student-index endpoint on one of the institution's campus subdomains, returning a JSON response that maps institutional student email addresses to first, middle, and last names; the tool reports that single response at roughly 192 KB. A second attached image showed a long, watermarked wall of the same email-and-name pairs. The post was captioned in Tagalog to the effect of 'one more prompt before we go inactive.' The institution has not issued a public statement, no independent media or researcher corroboration has been found, and this entry is recorded as 'unconfirmed' with the institution's name withheld.

August 4, 2026No record count stated by the threat actor. The single application response shown in the attached screenshot is reported by the interception tool at roughly 192 KB of name-and-email records, and a separately published text file is described as containing extracted email addresses records affected

Key Facts

Date of Incident
August 4, 2026
Date Discovered
August 4, 2026
Records Affected
No record count stated by the threat actor. The single application response shown in the attached screenshot is reported by the interception tool at roughly 192 KB of name-and-email records, and a separately published text file is described as containing extracted email addresses
Source
Nullsec Philippines / Nostra (Facebook)
Data Types Exposed
Student full names — first, middle, and last name (claimed)Institutional student email addresses (claimed)A published plain-text file described as containing extracted email addresses (claimed)
Response / Action Taken

No public statement from the institution has been observed at the time of this entry. Status will be updated if and when the school, the National Privacy Commission, or independent reporting confirms the access vector, the authenticity of the claimed dataset, its scope, and remediation.

Single-source notice: This incident is based on a single public Facebook post by a self-identified threat actor, reviewed via screenshots provided to this site — the specific post permalink was not independently captured. No mainstream news outlet has reported on it, no independent researcher has corroborated it, and the institution has not issued a public statement. The claim remains unverified and the institution's name has been redacted pending verification.

The post included a link to a plain-text file hosted on an anonymous file-sharing service, purportedly containing extracted email addresses, and two images displaying student names and institutional email addresses in bulk. Neither the link nor any of the personal data visible in those images is reproduced on this site, in line with the methodology of refusing to amplify breach material.

What Happened

On August 4, 2026, the Facebook account using the name Nullsec Philippines published a short post addressing a state university in Mindanao by name. The caption was a single line of Tagalog slang amounting to "one more prompt before we go inactive — peace," followed by a link to a text file, named for email addresses, hosted on an anonymous file-sharing service. The post was signed "- Nostra."

Two images accompanied the post. The first is a screenshot of an HTTP interception proxy — request and response panes side by side, with an inspector panel enumerating request attributes, cookies, and headers — showing a POST request to a student-index endpoint on a campus-specific subdomain of the institution and the JSON body returned in response. The second is a full-width wall of email-and-name records with the group's seal watermarked across the centre. At the time the post was captured it had been live for approximately 18 minutes and carried 25 reactions, 2 comments, and 1 share.

What the Screenshot Appears to Show

  • A single request returning bulk student records. The response pane renders a JSON object keyed by institutional student email address, with each key mapping to an object containing first-name, middle-name, and last-name fields. The interception tool reports the response at 192,541 bytes returned in 1,929 milliseconds — a single call, with no indication in the screenshot of pagination, a result cap, or a per-request limit.
  • A campus subdomain as the target host. The request's Host header points at a campus-specific subdomain rather than the institution's primary web presence. The subdomain prefix is withheld here; institutions in the same position should audit every campus and departmental subdomain, not only the main site.
  • A session cookie on the request. The request carries a PHP session cookie. Its presence does not by itself establish whether the endpoint enforced authentication — a session identifier may be issued to any visitor — so the screenshot alone does not settle whether this endpoint was reachable without a login or required a valid student or staff session.
  • An ordinary browser user-agent. The request presents a standard desktop Firefox user-agent string, consistent with a request replayed from a normal browsing session rather than an automated scanner signature.
  • A separately published file. The post links to a plain-text file, named for email addresses, on an anonymous file-sharing host. This site has not downloaded or reviewed that file, and the link is not reproduced here.
  • A bulk listing image. The second image shows several hundred email-and-name pairs legible at a glance across a dense wall of text, with more implied beyond the visible frame. No total record count is stated anywhere in the post.

Why the Methodology Treats This as 'Unconfirmed'

This entry is fully anonymized and tagged as 'Unconfirmed' because:

  • The only public source is the threat actor's own Facebook post, reviewed via screenshots provided to this site — the specific post permalink was not independently captured
  • No corroborating media coverage has been observed
  • No NPC finding is available
  • No public statement has been issued by the institution
  • The claim's central artefact — a linked file of extracted addresses — is operational breach material this site will not download, host, or link, so the record count and authenticity cannot be checked from the source itself

If the institution issues a statement, if reputable Philippine technology media independently reports the incident, or if the NPC publishes a finding, this entry will be updated and de-anonymized in line with the SchoolBreach.org methodology.

Threat-Actor Persona and Cross-References

The post is signed Nostra, a handle that recurs throughout the Nullsec Philippines campaign documented on this site. The same one-line, single-signature format appears in the technical institute in Laguna defacement claim (May 2, 2026), the "your users are affected again" post preceding the IBA College of Mindanao Inc. website breach (May 3, 2026), the state university in Metro Manila admissions-photo posts (July 4–5, 2026), and the private university in Metro Manila administration-tool source disclosure (July 14, 2026). The handle also appears in the greetz line of the private computer college campus in Rizal province database-leak claim (July 21, 2026).

The "before we go inactive" framing is the second wind-down signal from this persona in under a month: the July 14 post opened by stating the group was "not getting involved anymore" while still publishing screenshots of an exposed administration tool. A stated intention to stop posting has not, on the record tracked here, coincided with a stop in claims, and it carries no weight in this entry's assessment either way.

This is a separate institution from the one in the May 2026 credential-exposure claim against another state university in Mindanao; the two entries share an anonymized label because the methodology's geographic descriptor for Mindanao incidents is deliberately broad.

Why This Claim Warrants Attention

  • Full name plus institutional email is a complete phishing kit. The two fields shown in the response are precisely what is needed to send convincingly personalised mail to a student body at scale, addressed correctly and delivered to an address the recipient trusts. No password or financial field is needed for that outcome.
  • An institutional address list is a password-spray target list. If the addresses correspond to accounts in a single identity tenant, an attacker holding the full list can attempt common passwords against every account, which is materially different from attacking accounts discovered one at a time.
  • A single unpaginated response is a whole-directory response. A 192 KB JSON body returned to one request suggests the endpoint returns the roster in bulk rather than in bounded pages, which is the difference between an attacker enumerating records slowly and downloading them at once.
  • Directory endpoints are rarely monitored. Applications of this kind often log little, and a bulk read may leave no alert behind, meaning the institution may have no independent signal that this occurred.
  • If genuine, the data is already published. The post links the extracted file on a third-party host, so the material would be available to anyone who follows the link regardless of any action this site takes.

What Is Not Known

  • Whether the data is genuine. No independent party has verified that the screenshot depicts a live institutional endpoint or that the linked file contains real student records.
  • How many students are affected. No count is stated. The visible response size and image density suggest a substantial listing, but any figure derived from that would be an estimate, not a finding.
  • Whether authentication was required. The presence of a session cookie is ambiguous, and the screenshot does not show whether the endpoint rejects unauthenticated or unauthorised requests.
  • Whether other fields or endpoints are exposed. The response shown contains only names and email addresses; whether adjacent parameters return student numbers, contact details, or academic records is not established by the source.
  • How the endpoint was found. The post gives no account of the discovery method, and does not claim any credential compromise, defacement, or server-level access.
  • Whether the institution is aware. No public statement, advisory, or reply has been observed as of this entry.

Recommended Actions for the Institution

  1. 1.Treat the claim as credible until ruled out. Absent verification, the institution should assume a student directory containing names and institutional email addresses may have been retrieved in bulk and act on that basis.
  2. 2.Locate the endpoint and place it behind authentication and authorisation. A route that returns records for students other than the requesting user should require a valid session and an explicit authorisation check, not merely obscurity.
  3. 3.Cap and paginate any endpoint that returns lists. Bulk retrieval in a single response should not be possible for a directory route; enforce a maximum page size and require pagination.
  4. 4.Reduce the fields returned to the minimum the interface needs. If the calling page does not display middle names or email addresses, the response should not carry them.
  5. 5.Review web-server and application logs for that endpoint for at least the preceding 90 days. Establish whether bulk reads occurred, from which addresses, and over what period, and preserve the logs before rotation removes them.
  6. 6.Audit sibling campus and departmental subdomains for the same route. Where a codebase is deployed per campus, the same endpoint is likely reachable on every instance.
  7. 7.Monitor the student identity platform for password-spraying and credential-stuffing against the addresses that would appear in such a list, and enforce multi-factor authentication on student accounts.
  8. 8.Advise students directly to expect targeted phishing. Recipients who know a name-and-address list may be circulating are materially harder to deceive with mail that addresses them correctly.
  9. 9.Notify the National Privacy Commission within 72 hours under RA 10173 if the review finds any indication that personal data was put at risk — the legal trigger is risk to personal data, not certainty of exfiltration.
  10. 10.Issue a same-day public advisory. Silence in the face of a public claim leaves the threat actor's framing as the only public narrative. The contrast example on this site is the Assumption College of Davao ICTC advisory, issued the same day as that claim.
  11. 11.Preserve the threat actor's post and any linked material before it is altered or removed, for use in any NPC filing or law-enforcement referral.
  12. 12.Engage a forensic review of the hosting environment, not only the single application, to rule out broader access beyond the endpoint shown.

How to Prevent This Pattern

  1. 1.Authorise every data-returning endpoint, not just every page. Access control belongs on the route that returns records, since an interception proxy can call that route directly without the interface that normally wraps it.
  2. 2.Default to pagination and hard result caps on any list-returning route, so that a misconfiguration leaks a page rather than a roster.
  3. 3.Apply data minimisation at the response layer. Return identifiers the interface actually renders; a directory lookup rarely needs to emit every name component alongside a contact address.
  4. 4.Rate-limit and alert on volume anomalies. A single request returning tens of thousands of records, or a client retrieving an entire roster, should generate an alert rather than a log line nobody reads.
  5. 5.Maintain a subdomain inventory and test every campus deployment. Institutions running per-campus instances of a shared application inherit each instance's flaws, and attackers routinely target the least-maintained one.
  6. 6.Test with an interception proxy before release. The class of flaw documented here is found by replaying an application's own requests, which is exactly the check that should be run in-house first.
  7. 7.Publish a security contact and responsible-disclosure policy. Researchers and community members should have a private channel; absent one, they have only the public-Facebook-post channel.
Caragastate universitystudent directorystudent email exposureAPI enumerationdata exposuredatabase leakphishing riskstudent recordsNullsecPhilippinesNostraFacebookhacktivismunverifiedunconfirmed2026

Related Incidents

High

A private computer college campus in Rizal province

July 21, 2026

Critical

A state university in Mindanao

May 10, 2026

Critical

A private medical college in Cebu City

July 23, 2026

Know of a Breach?

Help us keep this tracker accurate and complete. Report school data breaches confidentially.

Report a Breach

Is This Entry Inaccurate?

If you represent the named institution or have evidence that corrects or updates this entry, you can request a correction or submit an official statement for publication.

We review all correction requests and respond within 5 business days. Verified corrections are applied promptly. Institutions may also submit a statement that will appear on this page as a right of reply.

Request a Correction

Protect Your School

Use our free tools and guides to assess your school's security posture.

Free Security ToolsGuides & Resources