A private college in CALABARZON

Single-source notice: This incident is based on a single public Facebook post by a self-identified threat actor, reviewed via a screenshot provided to this site. 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's preview shows four screenshots plus 24 more images that were not reviewed. Any personal data, credentials, or tokens those images may contain are not reproduced on this site, and neither is the database name shown in the screenshots.

What Happened

On November 9, 2026, the Facebook page The High Table published a post addressed to a private college in CALABARZON, tagging the college's official page. The post says the college's database "has been breached" and claims:

• 696 database tables
• More than 300,000 records across 14 tables that the page says it "disclosed"
• Administrator accounts and user login tokens, which the post itself says were "allegedly exposed"

The post adds that this is "a whole lot of sensitive information for an institution that's supposed to protect its students and staff," and closes with "Student deserves better," signed The High Table with the hashtags #TheHighTable and #Cybersecurity.

Unlike the page's earlier posts, this one does not say the page reported the issue to the college privately first, and it does not mention a deadline or a plan to release data.

What the Screenshots Appear to Show

The four screenshots visible in the post preview show a Linux terminal:

• A table-count query against the database's schema metadata, apparently used to support the 696-table figure. A table related to system feedback is named in the query.
• A full table listing for one database, ordered by name, split across three screenshots. The table names indicate a combined school-management system covering:
• Academic records: activity grades, attendance (including office-of-student-affairs attendance), conduct grades, club grades, certificate subjects and signatories, with separate senior high school tables
• Enrollment and finance: enrolled fees, a fees listing, payment logs, and blocked enrollments
• Administration: program-chair approvals, approval logs and messages, permits, and document trackers with remarks
• Identity and access: student-number records, a birthday log, sessions, user and instructor exports, and per-user access counts by module
• Files: document and file tables, and exam records

The terminal prompt shows the same short machine name, matching the page's initials, that appeared in the page's earlier screenshots. The queries appear to be run with a command-line MySQL client. The screenshots alone do not show whether the database was queried live on the college's server or from a copy on the actor's machine.

No row-level records, credentials, or tokens are visible in the four preview screenshots. The 14 tables the post says were "disclosed" are not identified in the preview.

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
• No corroborating report from Deep Web Konek, mainstream media, or an independent researcher has been observed
• No NPC finding is available
• No public statement has been issued by the institution
• The post's own wording ("allegedly exposed") hedges the credential and token claim, and the preview screenshots show table names, not records

The page's earlier claim against a state university campus in CALABARZON was raised to 'investigating' after Deep Web Konek reported it. That does not corroborate this separate claim.

If the institution issues a statement, if reputable Philippine media or Deep Web Konek independently reports the breach, 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

This is the second school claim by The High Table tracked on this site. On November 4–5, 2026, the page addressed a state university campus in CALABARZON with database screenshots taken from the same machine name, as part of the Deathnote Hackers (DNH) #MMM2026 Million Mask March. A dark-web forum account, blackhoundtht, later reposted that claim with a November 14, 2026 deadline.

Both institutions are in CALABARZON. This post does not carry the DNH or Million Mask March hashtags, and it drops the disclosure-first framing the page used in the earlier case.

Why This Claim Warrants Attention

• Login tokens allow account takeover without passwords. If valid session or login tokens were taken, an attacker could act as those users until the tokens expire or are revoked. Password resets alone do not invalidate them.
• Administrator access to a grades and enrollment system is an integrity risk. Grades, conduct marks, fee records, and enrollment blocks could be changed, and such changes are hard to detect after the fact.
• The system appears to hold minors' records. The senior high school tables suggest the database includes students under 18, whose data carries heightened protection.
• Finance and identity records are in the same database. Payment logs, student numbers, and birthday records together support targeted phishing and payment fraud against students and parents.
• The page has a recent pattern of escalation. In its earlier case, the page moved from a public post to a forum post with a release deadline within three days.

What Is Not Known

• Whether the access is real and current. The preview shows table names only; no records were visible.
• Which 14 tables were "disclosed" and whether "disclosed" means published, sampled, or only counted.
• How the database was reached. The post does not name a vulnerability or access path.
• Whether the token and administrator claim is true. The post itself says these were "allegedly" exposed.
• What the 24 unreviewed images contain. They may include samples of personal data.
• Whether the page will set a deadline or release data, as happened in its earlier case.

Recommended Actions for the Institution

1. 1.Treat the database as potentially copied. Plan the response on the basis that the listed tables may be in the actor's hands until the investigation shows otherwise.
2. 2.Invalidate every active session and login token and force re-authentication for all users. Rotate any token-signing secrets.
3. 3.Rotate every credential the system uses, including database, administrator, application, and service accounts, and review all administrator accounts for ones that should not exist.
4. 4.Preserve logs before remediation. Copy web server, application, and database logs to isolated storage, covering at least the last 90 days.
5. 5.Find and close the access path. Check whether the database server is reachable from the internet, and review the application for injection and file-disclosure flaws.
6. 6.Audit grades, conduct, enrollment, fee, and payment records for changes made by administrator accounts, and compare them against earlier backups.
7. 7.Notify the National Privacy Commission within 72 hours under RA 10173. The legal trigger is a real risk to personal data, not certainty of exfiltration, and the system appears to hold minors' records.
8. 8.Issue a same-day public advisory to students, parents, and staff explaining what is claimed, what has been done, and what they should watch for, such as payment requests that appear to come from the college. 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.
9. 9.Request removal of any images that show personal data, and preserve copies for the NPC filing.
10. 10.Engage an external review of the school-management system and its hosting.

How to Prevent This Pattern

1. 1.Keep student-records databases off the public internet and reachable only from the application server.
2. 2.Use short-lived, revocable session tokens, and store them hashed rather than in plain text.
3. 3.Separate administrator accounts from everyday accounts, with least privilege and multi-factor authentication.
4. 4.Split sensitive data across systems where practical, so a single breach does not expose grades, finance, and identity together.
5. 5.Log and alert on schema enumeration, exports, and bulk reads, so a full table listing or copy cannot be taken unnoticed.
6. 6.Publish a security contact and responsible-disclosure policy that routes reports straight to the IT office.
7. 7.Rehearse an incident response plan that includes the NPC 72-hour notice and a same-day advisory template.