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.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.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.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.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.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.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.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.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.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.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.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.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.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.Default to pagination and hard result caps on any list-returning route, so that a misconfiguration leaks a page rather than a roster.
- 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.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.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.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.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.