_explained / judging-system-sql-injection-exposes-login-credentials
HIGH PLAIN ENGLISH 5 min read

A Flaw in This Online Judging System Can Hand Attackers Your Entire Database — From Anywhere in the World

A publicly available exploit lets remote attackers bypass login and raid the database of a widely used electronic judging platform. Here's what you need to know.

💬
PLAIN ENGLISH EDITION

This article is written for general audiences — no security background needed. For the full technical analysis with CVE details, affected versions, and code-level breakdown, visit Intel Reports.

CVE-2026-7555: Electronic Judging System SQL Injection

Imagine a hacker sitting in a café halfway around the world, typing a single crafted line of text into a login box — and walking away with every score, every judge's credential, and every competitor's personal record your organization has ever stored.

Who's at Risk — and How Many People Are We Talking About?

The vulnerability, tracked as CVE-2026-7555 and rated HIGH (CVSS 7.3), lives inside itsourcecode Electronic Judging System 1.0 — a PHP-based platform used by schools, universities, coding competitions, talent contests, and academic intramural events to manage judging, scoring, and participant data. The software is freely distributed as a ready-to-deploy package, meaning it has been downloaded and stood up by countless institutions worldwide, many of them with limited IT security resources.

If your school's science fair uses it, if your university's programming contest relies on it, or if any organization you belong to runs intramural events tracked digitally — there is a real chance this flaw is sitting, unpatched, on a server right now. The people most exposed aren't just system administrators. They're students, faculty, coaches, judges, and participants whose names, contact details, and login credentials could all be sitting inside that database.

Making matters worse: a working exploit is already publicly available. That means an attacker doesn't need to be sophisticated. They just need a browser and a copy of the exploit code that's already circulating online.


What the Attacker Actually Does — No Jargon

Every time you log into a website, your username and password get handed to the server, which looks them up in a database. Normally, the software acts like a careful librarian — it takes your credentials, wraps them safely, and asks the database a polite, contained question: "Does this person exist?"

In the Electronic Judging System's login page (/intrams/login.php), that librarian isn't careful at all. The Username field accepts raw, unsanitized input — meaning if you type something that looks like a database command instead of a name, the system passes it straight through to the database engine as if it were a legitimate instruction. Attackers call this "SQL injection." In practice, it means someone can type a specially crafted username like ' OR '1'='1 — and the database, confused into thinking the logic is always true, unlocks the front door without ever checking a real password.

From there, the attacker isn't just inside one account. Depending on the database permissions configured on the server — and in many quick-deploy academic setups, those permissions are very broad — they can read every table in the database, extract all stored usernames and hashed or plaintext passwords, modify scores and records, and in worst-case configurations, execute system-level commands on the underlying server itself. The entire attack can happen remotely, over the public internet, without any physical access or prior knowledge of the system. No inside help needed. No special tools. Just a browser.


The Technical Detail That Security Researchers Need to Know

The vulnerability is a classic error-based / boolean-based SQL injection in an unauthenticated POST parameter within /intrams/login.php, specifically through the Username argument. Because the injection point sits on the authentication gate itself — before any session is established — it carries authentication bypass as a primary attack primitive, with full database read/write and potential remote code execution as secondary outcomes depending on server configuration. The flaw is categorized under CWE-89 (Improper Neutralization of Special Elements used in an SQL Command) and has been assigned a CVSSv3.1 base score of 7.3 (HIGH), with the attack vector marked as Network, complexity Low, and no privileges or user interaction required.


Has This Been Used in the Wild? Who Found It?

As of publication, no confirmed active exploitation campaigns have been reported — but that window may be short. The exploit has been publicly disclosed and is accessible, which historically means opportunistic scanning begins within days of publication. Vulnerability databases classify this situation with a clear warning: "The exploit is publicly available and might be used."

The discovery appears to have originated through source-code analysis of the itsourcecode package, which is distributed openly. Because itsourcecode packages are popular teaching and demonstration tools in Southeast Asian academic environments — particularly in the Philippines, Indonesia, and surrounding regions — institutions in those areas running unmodified versions of the 1.0 release are at the highest immediate risk. That said, the software has global distribution through open-source repositories, and any deployment anywhere running version 1.0 without a patch or workaround is exposed.

No specific threat actor group has been attributed. The current threat profile most closely resembles automated SQL injection scanning campaigns, which routinely probe known vulnerable PHP applications at scale using tools like sqlmap — tools that are free, widely used, and trivially pointed at a specific file path once that path becomes public knowledge.


What You Should Do Right Now — 3 Specific Steps

  1. Take the login page offline or restrict access immediately. If your organization is running itsourcecode Electronic Judging System 1.0, the fastest mitigation is to block public access to /intrams/login.php using your web server configuration (Apache: .htaccess deny rules; Nginx: location block with deny all) until a patched version is available or the code is manually remediated. If the system is only used internally, place it behind a VPN or firewall rule that prevents external internet access entirely.
  2. Audit your database for unauthorized access — starting now. Pull your MySQL or MariaDB query logs and look for anomalous login attempts to login.php containing characters like single quotes ('), double dashes (--), or the string OR 1=1. If you find evidence of successful exploitation, treat your database as fully compromised: rotate all credentials, notify affected users, and preserve logs for forensic review. If you're running MySQL 5.7 or MariaDB 10.3 and above, the general query log can be enabled with SET GLOBAL general_log = 'ON'; for retrospective checking.
  3. Patch the source code directly if you have developer access. The fix is straightforward for any PHP developer: replace raw query construction in login.php with prepared statements using PDO or MySQLi. Replace any instance of a query built by string concatenation of the $_POST['Username'] variable with a parameterized query — e.g., $stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?"); $stmt->execute([$username]);. This single change eliminates the injection vector entirely. If you are not the developer, contact itsourcecode directly and request an updated release patched against CVE-2026-7555.

CVE: CVE-2026-7555  |  CVSS: 7.3 HIGH  |  Affected Version: itsourcecode Electronic Judging System 1.0  |  Exploitation Status: Public exploit available, no confirmed active campaigns at time of publication.

// TOPICS
#sql-injection#authentication-bypass#remote-code-execution#unsanitized-input#php-vulnerability
// WANT MORE DETAIL?

The technical analysis covers the exact vulnerability mechanism, affected code paths, attack chain, detection methods, and full remediation guide.

Read technical analysis →