A private university in Bicol Region

Single-source notice: This incident is based on a single public post by a self-identified threat actor. 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.

What Happened

On April 23, 2026, a Facebook page operating under the name "Philippine CyberMafia" posted a screenshot claiming to have exploited a cross-site scripting (XSS) vulnerability on a subdomain of a private university in Bicol Region. The post was signed "~n", corresponding to the handle "nightfury" visible in the exploit payload.

The accompanying Taglish caption taunted the institution's administrators for failing to implement "simpleng pagsanitize lng ng inputs" ("just simple input sanitization"). The caption also addressed a named individual by first and last name — likely an IT or administrative staff member at the institution — whose name has been redacted here.

What the Screenshot Appears to Show

If authentic, the screenshot depicts:

• The institution's College of Maritime Education web page hosted on a maritime-focused subdomain of the institution's `.edu.ph` domain
• An executed JavaScript dialog (a `prompt()` or `alert()` modal) displaying the text "greetings from pcm hehe" and "~nightfury was here" — with the dialog's origin attribution naming the maritime subdomain, which confirms the code executed in the context of the institution's own origin
• A "Find" search feature and footer text reading "Search Item Found(s)," suggesting the XSS payload was injected through a search/find input that reflects user input into the page without escaping
• Pentester-style browser bookmarks (OffSec, Kali Tools, Kali Docs, Exploit-DB, Google Hacking, Deepseek AI Jailbreak), consistent with an actor using standard offensive-security tooling

Additional Security Observations

Separately from the XSS claim itself, the institution's domain was observed to have an expired TLS/SSL certificate around the same time. This is an independent finding — it did not cause the XSS issue — but it contributes to the overall picture of neglected web-security hygiene: browsers presenting certificate warnings to every visitor erode user trust and train users to click through warnings, which in turn makes phishing and attacker-in-the-middle attacks against the institution's community easier.

What Is Not Known

• Whether the XSS is reflected or stored — a reflected XSS requires a crafted URL to target each victim, while a stored XSS would persistently affect anyone visiting the affected page. The screenshot alone does not distinguish between them.
• The full scope of affected pages or endpoints — only the maritime-focused subdomain is shown; other institutional subdomains and the main domain are not demonstrated to be affected.
• Whether session or credential theft occurred — XSS is frequently chained to steal session cookies, tokens, or login credentials, but the actor did not publicly claim data theft in this post.
• Whether the actor has additional, undisclosed access — the public post may be a teaser for deeper compromise that has not been disclosed.
• The institution has not issued a public statement as of the date of this entry.

Why This Claim Warrants Attention

• Public proof of exploitability — a visible, origin-attributed JavaScript dialog is strong evidence that user input is reflected into the page without adequate sanitization or output encoding
• Search endpoints are classic XSS surfaces — reflected search queries that echo user input back are among the most common XSS vectors in legacy PHP and classic-ASP web applications
• Weaponization risk — the same vulnerability that produces a harmless-looking dialog can be used to steal student and faculty session cookies, harvest credentials via fake login overlays, or deliver malware to visitors of the page
• Subdomain contextual risk — if the affected subdomain shares session cookies with the main domain or other institutional services, the XSS may be usable to hijack accounts on those adjacent systems
• Pattern of targeting by the same actor group — the "Philippine CyberMafia" name was also used in a separate, unrelated claim against a state university in Ilocos Region in December 2025, where the alleged vector was SQL injection rather than XSS; this suggests ongoing opportunistic targeting of Philippine educational institutions by the group

Recommended Actions for the Institution

1. 1.Patch the vulnerable input — identify the search/find endpoint on the affected subdomain and apply contextual output encoding (HTML entity encoding for HTML contexts, JavaScript string escaping for JS contexts) to all reflected user input
2. 2.Deploy a Content Security Policy (CSP) — at minimum, restrict inline script execution to block injected `<script>` payloads
3. 3.Audit all other search, feedback, comment, and login forms — wherever user input is echoed back into a page on any institutional subdomain
4. 4.Rotate session secrets and force re-authentication — if there is any chance the actor captured session cookies before the public post, assume they are compromised
5. 5.Inventory subdomains — university environments frequently host legacy subdomains (departments, colleges, event sites) on aging PHP stacks; each is an independent attack surface that must be inventoried and hardened or retired
6. 6.Engage a security researcher or firm for a broader assessment — a threat actor posting a single XSS proof has likely found more issues than they disclosed publicly
7. 7.Renew the expired TLS/SSL certificate on the institution's domain(s) — browser warnings train users to click through security prompts, compounding phishing and session-hijack risk
8. 8.Support the named staff member rather than blame them — the post calls out an individual by name, but input-sanitization failures are an organizational issue (process, tooling, code review) rather than a single person's fault
9. 9.Preserve evidence — archive the Facebook post and screenshot before the actor or platform removes it

How to Prevent This Pattern

1. 1.Adopt a modern framework with built-in output escaping — React, Vue, Angular, Laravel Blade, and Django templates all escape output by default; prefer these over hand-rolled PHP echoes
2. 2.Enforce output encoding by default — never echo user input into HTML, JavaScript, or URL contexts without context-appropriate encoding
3. 3.Implement a strict Content Security Policy — `script-src 'self'` (without `'unsafe-inline'`) prevents most reflected XSS from executing even when input handling is flawed
4. 4.Use HttpOnly, Secure, and SameSite cookies for session tokens to reduce the blast radius of any XSS that does get through
5. 5.Deploy a Web Application Firewall (WAF) in front of legacy applications as defense-in-depth, with rules that block common XSS payloads
6. 6.Run automated SAST and DAST scans on institutional web properties on a recurring schedule, especially for college-specific subdomains that are often maintained by small teams
7. 7.Train web developers in secure coding — the OWASP Top 10 XSS guidance is free, widely available, and directly applicable
8. 8.Publish a security contact and responsible-disclosure policy so researchers can report findings privately instead of resorting to public Facebook posts