eastbaycyber

CVE-2026-44450: Critical SQL Injection in phpIPAM

CVE explainers 9 min read
SR
Security Research Desk Expert reviewed
Threat intelligence · Human-verified · Updated 2026-05-26
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief
Field Value
CVE ID CVE-2026-44450
CVSS score 9.8 Critical
Attack vector Network
Authentication required None
Patch status Upstream fix commit exists; exact first fixed release version could not be directly confirmed from retrieved primary sources

TL;DR - Critical SQL injection in phpIPAM via the vrf parameter. - Affects versions through 1.7.3; prioritize exposed instances. - No CISA-confirmed active exploitation, but urgency is high due to no-auth remote attack potential.

What happened and why it matters

CVE-2026-44450 is a CWE-89 SQL Injection vulnerability in phpIPAM. According to the NVD, phpipam/phpipam versions through 1.7.3 are affected because the file app/admin/routing/edit-bgp-mapping-search.php does not properly sanitize the vrf parameter before using it in SQL statements. NVD assigns a CVSS v3.1 base score of 9.8 (Critical) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

For defenders, the key point is not just that this is SQL injection, but that it is described as network exploitable, with no privileges required and no user interaction required. In operational terms, that combination makes it the kind of flaw that can move from disclosure to opportunistic scanning very quickly, especially if phpIPAM is exposed to the internet or broadly reachable from untrusted networks.

The affected version statement that can be supported from the available sources is “through 1.7.3,” meaning 1.7.3 and earlier are affected. An upstream remediation exists in commit 6654db6676fdd9f364f3ea1515db7fe4c8fcc620, but from the retrieved references, the first tagged fixed release version number could not be directly confirmed. In the absence of a confirmed release tag, defenders should assume that any deployment on 1.7.3 or earlier remains at risk unless they can prove the fix commit has been included or backported.

Exploitation status: in the wild, PoC, and what is actually known

As of the research context provided, CISA KEV does not list CVE-2026-44450, so there is no CISA-confirmed exploitation in the wild at this time. That is an important signal because many organizations use KEV as a triage input for active risk. However, absence from KEV does not mean the vulnerability is safe to defer. It only means there is no CISA-confirmed listing.

For public proof-of-concept status, a standalone PoC repository was not verified from the primary references available here. There is public disclosure in the sense that the CVE is documented in NVD and discussed in upstream GitHub references, and a secondary source claims public exploit disclosure. Because that claim is not from the vendor or a verified primary source, the most accurate statement is:

  • Exploitation in the wild: Not confirmed by CISA KEV
  • Public PoC: Not verified from primary references in the available source set
  • Public technical disclosure: Yes, via NVD and upstream code/issue references

In practice, defenders should assume that a critical unauthenticated SQLi in a widely reachable web application can attract scanning and copycat testing even without a polished PoC repo. SQL injection flaws are often reproducible from vulnerability descriptions and patch diffs alone, which increases urgency despite incomplete exploitation telemetry.

AnalystImpact · assess the risk

Affected versions, fixed status, and exposure assumptions

The most defensible affected-version statement is:

  • Affected product: phpIPAM
  • Affected versions: through 1.7.3
  • Affected component/file: app/admin/routing/edit-bgp-mapping-search.php
  • Unsafe parameter: vrf

That wording matters because security teams often need a clear inventory rule. If your CMDB, container manifest, package list, or deployment notes show phpIPAM 1.7.3 or older, treat the system as vulnerable until proven otherwise. If your environment uses a source checkout, custom image, or manually modified deployment, version strings alone may be misleading; in those cases, verify whether the upstream fix commit has been applied.

Patch status requires a careful distinction between code fix availability and release verification. The upstream fix commit is known: 6654db6676fdd9f364f3ea1515db7fe4c8fcc620. A related upstream pull request indicates the remediation involved both proper query escaping and restricting the search feature to the admin/authenticated section. However, because the retrieved sources did not directly confirm the first released fixed version tag, you should not claim a specific fixed version unless you verify it in your own release notes or repository history.

Version / State Status
1.7.3 and earlier Affected
First release containing commit 6654db6676fdd9f364f3ea1515db7fe4c8fcc620 Fixed, but exact version number not directly confirmed from retrieved primary sources
Customized or source-based deployment Unknown until commit-level verification is performed

What attackers could do

Because the flaw is a SQL injection in a PHP-based IP address management application, likely outcomes include unauthorized data access, unauthorized modification of records, and service disruption. Depending on the application’s database permissions and schema, an attacker may be able to enumerate network inventory, retrieve sensitive operational metadata, alter BGP-related records, or trigger backend SQL errors that aid further exploitation.

The actual blast radius depends heavily on deployment specifics. If phpIPAM uses a highly privileged database account, compromise impact may be broader than the vulnerable feature alone. If the application is internet-exposed or sits on a management network reachable by many internal users, attack opportunity also expands. Even if the vulnerable path was intended for admin use, the upstream remediation notes suggest authentication and query escaping both needed improvement, which should raise concern about exposure assumptions in existing deployments.

ResponderRunbook · act now

Detection and triage priorities

Start by identifying all phpIPAM instances and mapping them to versions. Prioritize systems that are internet-facing, reachable from partner networks, or accessible from low-trust internal segments. Then review web logs and upstream reverse proxy logs for requests to the affected path: /app/admin/routing/edit-bgp-mapping-search.php. Focus on suspicious values in the vrf parameter, especially characters and keywords associated with SQLi testing.

You should also correlate web activity with database error logs and application anomalies. SQL injection attempts often generate traceable indicators such as syntax errors, unusual UNION queries, access pattern spikes, or malformed requests containing ', ", %27, comment delimiters, or time-based payload elements. If you do not have high-fidelity phpIPAM-specific logging, use your web tier, WAF, or reverse proxy as the primary observation point.

Technical Notes

Suspicious web log patterns

Look for direct requests to the affected endpoint with SQL metacharacters in vrf:

/app/admin/routing/edit-bgp-mapping-search.php?vrf='
/app/admin/routing/edit-bgp-mapping-search.php?vrf=1%27%20OR%20%271%27%3D%271
/app/admin/routing/edit-bgp-mapping-search.php?vrf=1%20UNION%20SELECT
/app/admin/routing/edit-bgp-mapping-search.php?vrf=1%27%20AND%20SLEEP(5)--%20

Example grep for Apache or Nginx access logs

grep -Ei 'edit-bgp-mapping-search.php.*vrf=.*(%27|%22|union|select|sleep(|--|/*|or|and)' /var/log/nginx/access.log /var/log/apache2/access.log

Example Splunk query

index=web_logs ("edit-bgp-mapping-search.php")
| rex field=uri_query "(?i)vrf=(?<vrf>[^&]+)"
| search vrf="*%27*" OR vrf="*'*" OR vrf="*union*" OR vrf="*select*" OR vrf="*sleep(*" OR vrf="*--*"
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, http_method, uri, vrf, status

Example Sigma-style logic concept

title: phpIPAM edit-bgp-mapping-search suspicious vrf parameter
logsource:
  category: webserver
detection:
  selection:
    cs-uri-stem|contains: "/app/admin/routing/edit-bgp-mapping-search.php"
  keywords:
    cs-uri-query|contains:
      - "vrf=%27"
      - "vrf='"
      - "UNION"
      - "SELECT"
      - "SLEEP("
      - "--"
  condition: selection and keywords
level: high

Mitigation and patching guidance

The preferred remediation is to upgrade phpIPAM to the first release that includes upstream commit 6654db6676fdd9f364f3ea1515db7fe4c8fcc620. Because the exact fixed release number was not directly confirmed in the retrieved source set, security teams should validate release contents before closing the issue. If your deployment comes from source control, confirm the commit is present. If it comes from a package or container, verify the package changelog or image digest against vendor release notes.

If immediate upgrade is not possible, reduce exposure aggressively. Restrict access to phpIPAM management interfaces at the network layer, place the application behind authentication-aware reverse proxy controls where appropriate, and ensure the vulnerable admin/routing path is not reachable by untrusted users. Since upstream notes indicate a fix also involved allowing search only from the admin section for authenticated users, enforcing authenticated-only access to the relevant functionality is a reasonable short-term risk-reduction step, though it is not equivalent to a code fix.

Technical Notes

Check whether the fix commit exists in a source-based deployment

cd /var/www/phpipam
git rev-parse HEAD
git log --oneline --decorate --grep 6654db6676fdd9f364f3ea1515db7fe4c8fcc620
git branch --contains 6654db6676fdd9f364f3ea1515db7fe4c8fcc620

Upgrade from upstream source

If you manage phpIPAM as a Git checkout, update to a vendor-supported revision that includes the fix:

cd /var/www/phpipam
git fetch --all --tags
git pull --ff-only
git branch --contains 6654db6676fdd9f364f3ea1515db7fe4c8fcc620

If your process requires pinning to a specific release, stop and verify which release first contains the commit before deployment.

Short-term reverse proxy restriction example (Nginx)

Restrict access to the vulnerable endpoint to trusted admin networks only:

location = /app/admin/routing/edit-bgp-mapping-search.php {
    allow 192.0.2.0/24;
    allow 198.51.100.0/24;
    deny all;
}

Then reload:

sudo nginx -t && sudo systemctl reload nginx

Short-term Apache restriction example

<Location "/app/admin/routing/edit-bgp-mapping-search.php">
    Require ip 192.0.2.0/24 198.51.100.0/24
</Location>

Then reload:

sudo apachectl configtest && sudo systemctl reload apache2

These workarounds reduce exposure but do not remove the underlying SQL injection if reachable by an allowed client.

Incident response and validation checklist

If you discover an exposed vulnerable instance, treat it as potentially compromised until log review is complete. SQL injection into management software can result in quiet data theft or subtle record manipulation rather than obvious outages. Review recent changes to network inventory, BGP-related mappings, and administrative records. Also assess whether database credentials used by phpIPAM have excessive privileges.

After patching or restricting access, validate from both a defensive and operational angle. Confirm that the vulnerable path is no longer reachable from untrusted networks, verify the application still functions for authorized admins, and tune detections for the affected endpoint for at least several weeks after remediation. Attackers often continue probing published vulnerable paths after fixes become available.

References

For more information on network security practices, check out our articles on what is log retention and how to validate your SIEM and EDR detections without guesswork.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-05-26

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.