A private university in Metro Manila

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 July 14, 2026, the Facebook account using the name Nullsec Philippines publicly addressed the official Facebook page of a private university in Metro Manila. The post read, in full:

"I'm not getting involved anymore, but please fix your website. It's giving major 2011 energy. lmao — Nostra"

Unlike most Nullsec Philippines posts tracked on this site, this one makes no claim of data extraction, account compromise, or content replacement. The framing is explicitly the opposite: the actor states they are stepping back from further involvement and is instead publicly asking the institution to remediate what the two attached screenshots show.

Why This Is Classified as a Vulnerability Disclosure, Not a Breach or Defacement

This entry is tracked as a misconfiguration finding rather than a breach or website-defacement incident because:

• No unauthorized access is claimed. The actor does not describe logging into any system, extracting any file, or modifying any page.
• No data is claimed to have been taken. Nothing in the post or its attachments references student, staff, or applicant records.
• No content on the institution's site was altered. There is no marker page, no replaced homepage, and no reference to any defacement.
• The actor's own language frames this as a warning, not a claim of compromise — "not getting involved anymore" is a statement of restraint, addressed publicly to the institution rather than to the actor's usual audience of followers.

The finding is nonetheless recorded on this tracker because what the screenshots show — an unauthenticated, publicly reachable environment-diagnostic page and the plaintext source of a database-administration script — constitutes a real, exploitable misconfiguration, independent of whether this particular actor chose to act on it.

What the Screenshots Show

• A phpinfo() diagnostic page, reachable at the institution's main public domain, displaying the server's PHP version (8.0.30), the underlying Linux distribution and build details, loaded PHP extensions, and standard configuration file locations. This kind of page is a standard PHP debugging output that should never be reachable on a production server, since it gives an outside visitor a detailed map of the server's software stack.
• The raw source code of a third-party, single-file MySQL administration script ("PHP Mini MySQL Admin"), served as plaintext rather than executed by the server. The exposed source included the script's own access password and a hard-coded database username, password, and default database name. The specific credential values are not reproduced on this site.

Both screenshots show the browser address bar pointed at the institution's main public domain, indicating the exposures were reachable from the open internet rather than an internal-only network segment.

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 own framing (a warning rather than a claim of access) means there is no exploitation to independently verify — only the underlying misconfiguration, which is visible directly in the screenshots

If the institution issues a statement, if reputable Philippine technology media independently reports the finding, 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, including the St. Ignatius Technical Institute of Business and Arts Cabuyao Campus defacement claim (May 2, 2026), the "your users are affected again" post preceding the IBA College of Mindanao Inc. website breach (May 3, 2026), and the state university in Metro Manila admissions-photo posts (July 4–5, 2026). Across that history, "Nostra" posts range from data-claim disclosures to, as here, a purely advisory warning — the persona does not always frame a post as an attack claim.

Why This Finding Warrants Attention

• Live database credentials were exposed in cleartext, not just described. Source-code disclosure of a database-administration script is functionally equivalent to leaving a set of keys on a public counter — whether or not this particular actor used them, anyone else who found the same exposure could have.
• The exposure was on the institution's primary public domain, not an obscure or decommissioned subdomain, meaning it was easily discoverable by any visitor or automated scanner.
• A phpinfo() page left reachable in production is itself a recognized hardening failure, independent of the more serious admin-script exposure, and often indicates broader gaps in the deployment's security review process.
• The actor's restraint does not reduce the underlying risk. A single unscrupulous visitor finding the same two pages could have used the exposed credentials before the institution had a chance to remediate.

What Is Not Known

• Whether the exposed database credentials were valid at the time of the post, or had already been rotated, is not confirmed from the public post alone.
• How long the phpinfo() page and the admin-script source had been reachable before this post is not known.
• Whether any other party accessed either exposure before this disclosure cannot be determined from a single public post.
• Whether the institution has since remediated either exposure has not been publicly confirmed.

Recommended Actions for the Institution

1. 1.Immediately remove or restrict the phpinfo() diagnostic page from the production web root; it should never be reachable outside a controlled debugging session.
2. 2.Investigate why the database-administration script's source was served as plaintext rather than executed — this typically indicates a misconfigured file extension, a misplaced file outside the PHP execution path, or a web-server rule serving PHP files as static text under certain conditions.
3. 3.Rotate the exposed database credentials and the script's own access password immediately, treating both as compromised regardless of whether misuse is confirmed.
4. 4.Remove or properly restrict the database-administration script from public reach entirely — tools of this kind should sit behind authentication, IP allow-listing, or a VPN, never on the open internet.
5. 5.Audit web-server configuration for other files served as plaintext instead of executed, since the same misconfiguration class may affect other scripts on the same host.
6. 6.Review database access logs for the affected credentials' lifetime to rule out prior unauthorized use.
7. 7.Issue a short public acknowledgment noting the report was received and the exposure addressed — a brief, factual response is preferable to silence, even for a finding this narrow in scope.
8. 8.Establish a security contact or responsible-disclosure channel, so that future findings of this kind reach the institution privately rather than through a public social-media post.

How to Prevent This Pattern

1. 1.Disable or gate phpinfo() and other diagnostic endpoints in production as a standard step in every deployment checklist.
2. 2.Never deploy third-party administrative tools (database admin panels, file managers, debug consoles) without authentication in front of them, regardless of how obscure the URL seems.
3. 3.Configure the web server to explicitly deny execution or serving of unexpected file types, so a misconfigured handler cannot serve script source as plaintext.
4. 4.Keep credentials out of application source entirely where possible, using environment variables or a secrets manager instead of hard-coded values in a script.
5. 5.Run periodic external exposure scans of the production domain for common misconfiguration signatures — exposed diagnostic pages, default admin panels, and publicly readable source files — before an outside party finds them first.