Skip to content

v7.3.0 Security Updates (severity: high) , App Passwords feature, API keys modernisation, bug fixes

Latest
Latest

Choose a tag to compare

View all tags
@barryo barryo released this 30 Jun 18:30
v7.3.0
120d975

INEX is pleased to announce the immediate availability of IXP Manager v7.3.0. This is primarily a security release following a responsible disclosure and subsequent internal hardening. Both issues have a high severity. This release also includes some bug fixes, improvements, and new features.

⚠️ All IXP Manager users should upgrade to v7.3.0.

Release Summary

git --no-pager diff --shortstat v7.2.0
 316 files changed, 5178 insertions(+), 3949 deletions(-)

Upgrade Instructions

The official upgrade instructions can be found here. Follow these, including the database migrations.

Our Continuing Security Commitment & EU CRA Alignment

As IXP Manager powers critical internet infrastructure globally, security is core to our processes, and this is the fourth successive release of IXP Manager that primarily focuses on security. We have also used third-party reporting as a catalyst to perform proactive internal audits of our codebase, leading to the discovery and immediate mitigation of additional vulnerabilities.

Aligning with the EU Cyber Resilience Act (CRA)

With the European Union’s Cyber Resilience Act mandatory reporting requirements taking effect on September 11, 2026, INEX is cognisant of our legal role as an Open-Source Software Steward.

To meet these obligations and ensure the highest standards of transparency for the IXP community, we have reviewed and updated our Security Policy.

Key updates you should be aware of include:

  • Standardised Disclosures via GHSA: Starting with this release, we are utilising GitHub Security Advisories (GHSA). This ensures our security announcements map to official CVEs and generate machine-readable vulnerability data (such as OSV formats). This allows the IXPs running our software to seamlessly feed our security updates into their automated dependency scanners and asset management pipelines.

  • Upstream Regulatory Controls: Our policy acknowledges the reporting windows required by ENISA for actively exploited vulnerabilities.

  • Reporting Methods: You can also submit security issues securely via GitHub here, and we have published a PGP key for our security@ixpmanager.org channel.

Security Advisory: Vulnerabilities Resolved in v7.3.0

Impact: High (Privilege Escalation & Unauthorised Access)

Target Audience: All IXP Manager Administrators

Summary

We have released IXP Manager v7.3.0 to address two high-security vulnerabilities. All users are strongly urged to upgrade immediately.

Identified Issues

  1. Privilege Escalation (CVE-PENDING) (Severity: 8.8/10)
    A confirmed vulnerability allows an authenticated, non-administrative user to elevate their privileges to administrator status. This was responsibly disclosed via security@ixpmanager.org.

    Note: The risk of this vulnerability is significantly minimised if administrative functions are restricted according to our Securing Administrative Functions documentation.

  2. Broken Object-Level Authorisation (CVE-PENDING) (Severity: 8.3/10)
    Following the initial report of (1) above, our development team conducted a proactive internal audit. During this review, we identified and corrected an issue in which an authenticated user could view and edit resources belonging to another user without authorisation.

    (Historical note: A similar proactive audit was conducted following our v7.2.0 grey-box penetration test, reflecting our ongoing commitment to thoroughly investigating and hardening the platform when issues are raised.)

Remediation

Both issues are addressed in this v7.3.0 release. Please upgrade to v7.3.0 as soon as possible.

Acknowledgments

We would like to sincerely thank Bakabaka_9 for responsibly disclosing the privilege-escalation vulnerability to us, providing high-quality details, and reviewing and agreeing to our planned release schedule.

New Features

Application-Specific Passwords

Application-Specific Passwords are often referred to as App Passwords or Device-Specific Passwords.

In some developer or modern API contexts, they are also referred to as Personal Access Tokens (PATs), but for mail servers and end-user devices, App Passwords is the standard terminology used by major providers like Microsoft, Google, and Apple.

App Passwords can be used, where necessary, to bridge the gap to modern security standards when a required system creates a classic compliance headache, such as a lack of direct support for Two-Factor Authentication (2FA). One such example is Dovecot, the world's leading email backend platform for IMAP and POP3 access.

IXP Manager implements an application-specific password manager for the convenience of IXPs who need it and who do not have an alternative system.

See the documentation here.

Improvements

API Key Modernisation

We have reviewed the creation, format, use and expiry policies of API keys against modern web application standards. These changes mean:

  1. The format of API keys has changed - see the documentation here.
  2. Expiry dates are now mandatory, with a maximum of 12 months. All existing keys with no expiry date have been set to expiry 12 months from when the database migration runs.
  3. Users will get an email 14-days in advance of API key expiry, providing them with the opportunity to rotate the key.
  4. New API keys are now SHA-256 hashed in the database, with no copy kept by IXP Manager.
  5. Expired API keys are deleted from the database after 28 days (this was 7 days previously).
  6. We are deprecating the use of API keys as part of an HTTP GET parameter.

Transition from Old-Style API Keys to New-Style

Existing API keys will be given a 12-month expiry date. They will continue to work until they expire.

We would recommend rotating existing API keys to the new style, as we will remove support for the older style in a future release.

Deprecation of Providing the API Key as a URL Parameter

This legacy method is now deprecated in favour of providing your key as an HTTP header parameter. In this 7.3 release, this feature is still enabled, but IXP Manager will write notices to the log file to inform you that it is deprecated.

We recommend that you identify any uses via GET by examining the logs, migrate them to HTTP headers, and rotate the key to the new format.

Other Improvements

  • Declare parameters with null default as nullable (deprecated in PHP 8.4) via #975
  • Fixes to data in the development Vagrant database
  • A number of improvements to customer pre-deletion checks and feedback
  • After making api routes accessible under /admin prefix, some sample scripts needed updating #979
  • Code review to replace old documentation links #983
  • Remove base href. It impacts copying a nav-tab link, and we don't have any other occasions we use relative URI's #994
  • Remove GitHub workflows workaround for psalm/psalm-plugin-laravel#415 (#991)
  • Update MANRS membership lookup to Observatory v2 API endpoint (#995) (@kolobus)
  • Framework and frontend assets updated
  • ~200 baseline psalm issues removed and fixed

Bug Fixes

  • Nagios config for birdseye-daemons ignores service_definiiton parameter #971
  • Fix looking glass "route details" page containing no details #974
  • Correct IXPM-OBJECT/IXPM-KEY in default rir templates (#978) (via @listerr)
  • Use url helper to generate maintenance mode default logo - ensures logo works when hosted under sub-path #993
  • Customer/member overview tab: link to multip2p graph from top peers list. Fixes #986

CI Results for this Release

❯ ./vendor/bin/phpunit
PHPUnit 11.5.55 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.4.22
Configuration: /Users/barryo/dev/ixpm-inex/phpunit.xml

...............................................................  63 / 538 ( 11%)
............................................................... 126 / 538 ( 23%)
............................................................... 189 / 538 ( 35%)
............................................................... 252 / 538 ( 46%)
............................................................... 315 / 538 ( 58%)
............................................................... 378 / 538 ( 70%)
............................................................... 441 / 538 ( 81%)
............................................................... 504 / 538 ( 93%)
..................................                              538 / 538 (100%)

Time: 03:37.716, Memory: 113.00 MB

OK (538 tests, 4197 assertions)

❯ ./vendor/bin/psalm --use-baseline=psalm-baseline.xml

Running on PHP 8.4.22, Psalm 6.16.1@f1f5de594dc76faf8784e02d3dc4716c91c6f6ac.

JIT acceleration: OFF
You can enable JIT acceleration (experimental) with --force-jit.

Target PHP version: 8.4 (inferred from composer.json).

Scanning files...

Analyzing files...

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  60 / 569 (10%)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 120 / 569 (21%)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 180 / 569 (31%)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 240 / 569 (42%)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 300 / 569 (52%)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 360 / 569 (63%)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 420 / 569 (73%)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 480 / 569 (84%)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 540 / 569 (94%)
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

------------------------------

       No errors found!

------------------------------

Checks took 15.34 seconds and used 1,879.895MB of memory
Psalm was able to infer types for 90.2446% of the codebase

Contributors

kolobus and listerr
Assets 2
Loading