A university in Bicol Region

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. 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 carries attachments that display personal data belonging to identifiable students — full names, student identification numbers, and identification photographs, some with names printed into the image itself. None of that material, and no filename, record value, or identifying detail drawn from it, is reproduced on this site, in line with the methodology of refusing to amplify breach material.

What Happened

On August 1, 2026, a Facebook page operating under the name CrimsonSec Philippines published a post addressed directly to the administration of a university in Bicol Region. The post is signed -Ph.0xUnknown404 and closes with a "Special Greetingz" line naming Nullsec Philippines, St0pc0rrupti0n, and Black Bytes.

In substance, the post states that the institution's student information and accounting system — described as "the portal every student logs into" — contains a vulnerability, that the actor located and exploited it, and that the disclosure was made publicly rather than privately. It claims the actor observed tens of thousands of student records inside the system, and characterizes the stored passwords as crackable within minutes and frequently reused across the students' other accounts. The post asserts that nothing was copied and nothing was sold, states that no demands are being made, and closes with the line that if the actor found the flaw, someone else has as well.

Three images accompany the post. The claim is therefore structured as a public shaming disclosure rather than an extortion attempt or a data sale — a framing that has recurred across several 2026 claims tracked on this site.

What the Attached Screenshots Appear to Show

• A student roster spreadsheet. One screenshot shows a tabular export with a student identification number column, a full-name column, an image-filename column, several numeric code columns, an uppercase single-word label column, and a free-text status column carrying values consistent with records administration — entries reading as verification states, review flags, and upload-pending markers. Several columns are covered with heavy red marker bars applied by the poster, but the identification-number and full-name columns were left visible; the self-redaction is partial, not complete.
• A bulk directory of student identification photographs. A second screenshot shows a file-manager grid of several hundred portrait photographs in the standard format of school identification pictures, stored under randomized alphanumeric filenames. A number of the images have the subject's name printed into the photograph itself. The visible grid is a fraction of a longer scroll, so the total count in the directory is not determinable from the screenshot.
• Roughly a hundred database table exports. A third screenshot shows a file-manager grid of CSV files following a two-part naming convention — one prefix corresponding to a queueing module and one to the student information and accounting system. The visible filenames map to functional areas including enrollment and enlistment, assessment, class scheduling and attendance, curriculum and departments, credentials and clearance, examinations, discounts, deposits, banking and payments, funds, and graduation awards. As with the photograph directory, the visible grid is a partial view of a longer listing.

Taken together, the attachments are consistent with table-level export of the student information system and bulk retrieval of the associated photograph store, rather than with viewing individual records through the portal's normal interface. That observation sits in tension with the post's own statement that nothing was copied, and the institution's assessment should proceed on the assumption of export until logs establish otherwise.

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 media coverage has been observed
• No NPC finding is available
• No public statement has been issued by the institution
• The post's claims about password strength and password reuse are the actor's characterization and cannot be assessed without access to the system's credential storage

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 signing persona Ph.0xUnknown404 has one prior appearance in this dataset: the handle was listed under the "Special Greetings" banner of the July 25, 2026 WordPress credential claim against a private college in Cebu City, signed by Ph.Bl4ke. This post is the first tracked incident in which the persona appears as the signing actor rather than as a greetz mention.

CrimsonSec Philippines follows the same trajectory. The name previously surfaced only in greetz lines — in the same July 25 Cebu claim, and in the June 2, 2026 credential-extraction claim against a private Catholic university in Mindanao signed by Nullsec Philippines personas. This is the first claim on this site posted from the CrimsonSec Philippines account directly.

The greetz line names Nullsec Philippines, St0pc0rrupti0n, and Black Bytes — the same three that appear alongside CrimsonSec in the July 25 Cebu post. Black Bytes additionally appears across the Storm Breaker Security PH claims tracked here, including the Malabon senior high school defacement (March 14, 2026) and the Cavite private college SQL-injection claim (January 12, 2026). The overlap places this account inside the same extended-collective network documented elsewhere in this dataset rather than as an unaffiliated emerging actor, and a second post from within that network does not constitute independent corroboration under this site's methodology.

Why This Claim Warrants Attention

• The claimed dataset is a full minor-inclusive identity set. Name, photograph, home address, contact number, date of birth, and parent details in combination are sufficient for identity fraud, targeted social engineering against families, and — because student identification photographs are involved — abuse in fraudulent enrollment or document forgery. Many records in a university student information system belong to individuals who were minors at the time of enrollment.
• Password exposure extends past the institution. The post's claim that credentials are reused on other accounts, if accurate, means the exposure does not stop at the portal. Students who reused a portal password on email or social accounts are at risk regardless of what the institution does to its own system.
• Accounting data raises financial-fraud exposure. The table names visible in the screenshots point at assessment, billing, deposits, banking, and payment modules. Records in these areas support convincing tuition-payment fraud against students and parents.
• The actor asserts the flaw is discoverable. The post's closing claim — that if they found it, someone else has — is unverifiable, but a vulnerability in a public-facing student portal is reachable by anyone, and disclosure by a public post rather than a private channel means any reader can begin looking for the same flaw from today.
• Public attachments are already circulating. The personal data shown in the attachments was published to a public Facebook page. Whatever the institution concludes about the underlying access, that specific exposure has already occurred.

What Is Not Known

• The vulnerability class and access vector. The post says only that a vulnerability existed and was exploited. It does not identify whether the flaw was an injection, a broken access control, an authentication bypass, an exposed administrative interface, or something else.
• Whether data was exported. The post says nothing was copied; the attachments are consistent with export. Only the institution's application, database, and web server logs can settle this.
• The true record count. "Tens of thousands" is the actor's figure. The screenshots do not establish a total, and no independent count exists.
• How passwords are stored. The claim that passwords are crackable in minutes implies weak or absent hashing, but the post provides no evidence for that characterization and none is reproduced here.
• How long access persisted. No indication is given of when the vulnerability was first exploited or whether access remains available.
• 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 it is ruled out. Absent verification either way, the institution should proceed on the assumption that the student information and accounting system was accessed and that its contents may have been exported.
2. 2.Take the portal offline or place it behind restricted access while the vulnerability is located. A public-facing system with an unidentified, publicly-claimed flaw should not continue serving traffic during triage.
3. 3.Preserve logs before any remediation touches the system. Application, database, web server, and authentication logs — plus file-access records for the photograph store — should be copied to isolated storage immediately, since patching and restarts frequently destroy the evidence needed to scope the incident.
4. 4.Audit access logs for at least the preceding 90 days. The post gives no indication of when access began, and a vulnerability of this kind commonly carries long dwell time. Look specifically for bulk-read patterns, sequential record enumeration, and mass retrieval from the photograph directory.
5. 5.Force a password reset across every student, faculty, and staff portal account, and invalidate all existing sessions rather than resetting only accounts that appear in the screenshots.
6. 6.Verify how portal passwords are stored and migrate to a modern password-hashing scheme if the review finds unsalted, legacy, or reversible storage. The claim of minutes-to-crack credentials should be treated as an assertion to disprove with evidence, not dismissed.
7. 7.Rotate database, service, and integration credentials used by the student information and accounting system, including any credentials embedded in configuration files reachable from the application server.
8. 8.Notify the National Privacy Commission within 72 hours under RA 10173. The legal trigger is risk of harm to personal data, not certainty of exfiltration, and the categories described here — identity data, contact data, minors' data, and financial records — sit squarely inside the notification threshold.
9. 9.Issue a same-day public advisory to students, parents, and staff, telling them plainly what is claimed, what is known, and what to do. It should include specific guidance to change any password reused from the portal on other services and to expect fraudulent tuition-payment and enrollment-related messages. 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.
10. 10.Engage an external forensic review covering the full hosting environment, not only the portal application, to rule out lateral movement, persistence, and access to adjacent systems sharing the same infrastructure.
11. 11.Request removal of the published attachments through the platform's reporting process on the basis that they publish identifiable personal data, including images of individuals, and preserve archived copies for any NPC filing or law-enforcement referral before doing so.
12. 12.Establish a single point of contact for affected students and parents who have questions, rather than routing them through general enrollment or registrar channels.

How to Prevent This Pattern

1. 1.Subject student portals to authenticated security testing before each academic term. Student information systems concentrate the highest-value personal data on a campus and are the most heavily used public-facing application the institution operates.
2. 2.Enforce authorization checks at the data-access layer, not only in the interface. Most bulk-extraction incidents in student portals trace to a request path that returns records the authenticated user was never meant to see, rather than to a broken login.
3. 3.Rate-limit and monitor for bulk-read behavior. Alerting on sequential record enumeration and unusual export volume converts a silent months-long extraction into a same-day detection.
4. 4.Store credentials using a current memory-hard hashing algorithm with per-user salts, and require multi-factor authentication for administrative and staff accounts on the portal.
5. 5.Separate the identification-photograph store from the web root and serve images only through authorized, expiring references. Bulk photograph retrieval is a recurring feature of these claims and usually indicates a directly reachable file store.
6. 6.Apply retention limits to student records and archive graduated cohorts out of the live system. A live portal holding every record the institution has ever created maximizes the impact of any single flaw.
7. 7.Publish a security contact and responsible-disclosure policy. Every claim in this dataset that arrived by public Facebook post arrived that way in part because no private channel was advertised. A monitored security address gives a finder somewhere to go that is not a public page.