/

CVE-2026-116061

Severity:

HIGH RISK

(7.3)

SQL Injection (CWE-89) in SourceCodester edit_dealer.php

CVE-2026-116061

Deferred

Vulnerability type

Category:

SQL Injection

CWE:

CWE-74, CWE-89

Impact:

Database compromise and unauthorized data manipulation

Severity:

HIGH RISK

(7.3)

CVSS version:

3.1

Catch this CVE while code is being written

Detect vulnerable code directly in pull requests, so CVEs are fixed before merge.

Summary

SourceCodester Performance Indicator System 1.0 contains a SQL injection vulnerability in the Contact parameter processed by edit_dealer.php.

A remote attacker may be able to manipulate database queries, potentially accessing, altering, or deleting data when the affected endpoint is reachable and input is not safely handled.

SourceCodester Performance Indicator System 1.0 contains a SQL injection vulnerability in the Contact parameter processed by edit_dealer.php.

A remote attacker may be able to manipulate database queries, potentially accessing, altering, or deleting data when the affected endpoint is reachable and input is not safely handled.

Affected context

The vulnerability occurs in the dealer-editing functionality of SourceCodester Performance Indicator System 1.0, specifically in /opils/staff/edit_dealer.php. It becomes risky when the endpoint is remotely accessible and the Contact argument is incorporated into database queries without adequate parameterization or validation.

The vulnerability occurs in the dealer-editing functionality of SourceCodester Performance Indicator System 1.0, specifically in /opils/staff/edit_dealer.php. It becomes risky when the endpoint is remotely accessible and the Contact argument is incorporated into database queries without adequate parameterization or validation.

Exploit preconditions

  • Attack surface: The remotely reachable dealer-editing endpoint
  • Required access: Access sufficient to submit requests to the affected functionality; authentication requirements depend on deployment configuration
  • Trigger point: Processing of the Contact argument by edit_dealer.php
  • Why exploitation is possible: User-controlled input may influence SQL query construction without reliable separation between data and query syntax
  • Attack surface: The remotely reachable dealer-editing endpoint
  • Required access: Access sufficient to submit requests to the affected functionality; authentication requirements depend on deployment configuration
  • Trigger point: Processing of the Contact argument by edit_dealer.php
  • Why exploitation is possible: User-controlled input may influence SQL query construction without reliable separation between data and query syntax

Why this happens

The underlying issue is SQL injection, mapped to CWE-89, with a related relationship to CWE-74 for improper interpretation of externally influenced input.

The insecure pattern occurs when request data is concatenated into database statements or otherwise interpreted as part of query syntax. Without parameterized queries and appropriate input handling, the database may process attacker-controlled content as executable SQL rather than ordinary data.

The underlying issue is SQL injection, mapped to CWE-89, with a related relationship to CWE-74 for improper interpretation of externally influenced input.

The insecure pattern occurs when request data is concatenated into database statements or otherwise interpreted as part of query syntax. Without parameterized queries and appropriate input handling, the database may process attacker-controlled content as executable SQL rather than ordinary data.

Potential impact

  • An attacker may retrieve sensitive application or database records
  • Database contents could be modified or deleted
  • Authentication or authorization data could be exposed or altered
  • The application may become unavailable if destructive queries are accepted
  • Confidentiality and integrity of related business data could be affected
  • An attacker may retrieve sensitive application or database records
  • Database contents could be modified or deleted
  • Authentication or authorization data could be exposed or altered
  • The application may become unavailable if destructive queries are accepted
  • Confidentiality and integrity of related business data could be affected

General mitigation guidance

Mitigation generally focuses on removing direct influence of request data over SQL syntax.

Common defensive patterns include:

  • Use parameterized queries or prepared statements for all database operations
  • Apply centralized data-access abstractions that separate values from query structure
  • Validate input according to the expected contact-data format and length
  • Use database accounts with only the permissions required by the application
  • Avoid exposing administrative data-management endpoints unnecessarily
  • Treat client-supplied values as untrusted even when authentication is present

Mitigation generally focuses on removing direct influence of request data over SQL syntax.

Common defensive patterns include:

  • Use parameterized queries or prepared statements for all database operations
  • Apply centralized data-access abstractions that separate values from query structure
  • Validate input according to the expected contact-data format and length
  • Use database accounts with only the permissions required by the application
  • Avoid exposing administrative data-management endpoints unnecessarily
  • Treat client-supplied values as untrusted even when authentication is present

How teams detect issues like this

Organizations can look for this weakness through:

  • Static analysis rules identifying string concatenation or interpolation in SQL statements
  • Code review checks for request parameters passed directly into database APIs
  • Dynamic testing that uses safe, controlled input variations to identify query manipulation behavior
  • Web-application firewall or database monitoring policies for anomalous query patterns
  • CI security policies requiring parameterized database access
  • Automated review tools that flag common SQL construction anti-patterns

Organizations can look for this weakness through:

  • Static analysis rules identifying string concatenation or interpolation in SQL statements
  • Code review checks for request parameters passed directly into database APIs
  • Dynamic testing that uses safe, controlled input variations to identify query manipulation behavior
  • Web-application firewall or database monitoring policies for anomalous query patterns
  • CI security policies requiring parameterized database access
  • Automated review tools that flag common SQL construction anti-patterns

Sources

SourceLink
github.comgithub.com/hubdk01/cve/issues/12
vuldb.comvuldb.com/cve/CVE-2026-116061
vuldb.comvuldb.com/submit/999428
vuldb.comvuldb.com/vuln/426144
vuldb.comvuldb.com/vuln/426144/cti
sourcecodester.comsourcecodester.com/

Frequently asked

questions

Yes, the affected functionality may be reachable over the network. Exploitability depends on deployment exposure, authentication controls, and whether requests can reach the vulnerable endpoint.

Not necessarily. The required access depends on how the application protects the dealer-editing function and its surrounding routes.

Use parameterized queries or prepared statements and ensure that request values are passed as data rather than concatenated into SQL statements.

Combine secure database APIs, context-appropriate input validation, least-privilege database accounts, code review, and automated testing for injection weaknesses.

Yes, the affected functionality may be reachable over the network. Exploitability depends on deployment exposure, authentication controls, and whether requests can reach the vulnerable endpoint.

Not necessarily. The required access depends on how the application protects the dealer-editing function and its surrounding routes.

Use parameterized queries or prepared statements and ensure that request values are passed as data rather than concatenated into SQL statements.

Combine secure database APIs, context-appropriate input validation, least-privilege database accounts, code review, and automated testing for injection weaknesses.

Find out what's already
exploitable in your codebase.