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

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 file...

v7.2.0 Security Release, Security Improvements and Combined P2P Graphing

INEX, the internet peering point for Ireland are pleased to announce the immediate availability of IXP Manager v7.2.0. This is primarily a security release following an independent security audit by ENISA and follow-up internal hardening.

⚠️ All IXP Manager users should upgrade to v7.2.0. Please note that v6 of IXP Manager is no longer supported because the versions of many of its underlying requirements (for example, PHP and Laravel) have reached their end of life.

This release also includes some bug fixes, improvements, and new features. In particular, we are delighted to introduce our new combined peer-to-peer graph functionality.

This release includes contributions via the IXP Manager Sponsorship Program, and we’d like to extend our gratitude to BCIX (Berlin), NIX (Norway), INX ZA (South Africa), LONAP (London), GRIX (Greece), InterLAN (Romania) and SLIX (Salt Lake, USA).

🚨 We do need more sponsors, and if you are interested, please contact us.

Upgrade Instructions

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

NB: The security enhancements introduced in v7.1.0 to secure access to administrative functions included a default setting that allowed older, unsecured URLs to continue working. This release, v7.2.0, now reverses that default and blocks access to the older URLs by default. See the transition documentation here.

Security

In 2022, ENISA, the European Union Agency for Cybersecurity, was tasked with establishing and rolling out the Cybersecurity Support Action Programme, a fund for the provision of cybersecurity services to support Member States. In Ireland, the NCSC (the Irish National Cybersecurity Centre) was tasked with administering this initiative.

INEX applied to this program for a web application vulnerability assessment and was accepted. During February 2026, a team from S2 Grupo, a firm specialising in cyber i​Intelligence and mission-critical systems operations, conducted a seven-day "grey box" penetration test on the latest release of IXP Manager (v7.0.1).

Not only was this an exercise that benefits INEX in Ireland, but it also benefits all EU member states, as there is at least one IXP in each country using IXP Manager, for a total of 60 IXPs in the EU and at least 260 worldwide.

S2 Grupo identified and categorised three medium-risk and one low-risk vulnerability. These have been addressed in this release and are detailed below. Furthermore, these findings prompted our development team to conduct a proactive internal audit and to use a new technique to identify and resolve several potential XSS-related issues.

INEX takes cybersecurity seriously, both as the primary IXP in Ireland and as the open-source steward of the IXP Manager project. We were pleased to participate in this funded assessment and are gratified that our secure coding methodology proved effective, with no issues rated high or critical found. We are proud that this collaboration between INEX, ENISA, S2 Grupo, and the NCSC contributes to the security of the global internet exchange community.

Penetration Test Details

The penetration test results included three medium and one low-risk vulnerability.

[VULN-01] Unsecured input data management – Persistent Cross-Site Scripting (XSS)

Two instances of an XSS vulnerability were found, and both have been corrected in this release. Exploitation requires administrative-level access.

We also ran an internal program to detect additional XSS vulnerabilities and remediated them, including one reflected XSS vulnerability. Like those found by ENISA, these all required administrative access.

[VULN-02] Lack of Headers – X-Frame-Options and Content Security Policy

This vulnerability is now IXP Manager-specific and applies to any web application. The report found:

It was identified that the X-Frame-Options header was missing from the server responses.

The X-Frame-Options header allowed specifying whether a frame or iframe was permitted to embed the web content. Websites could use it to prevent clickjacking attacks by ensuring their content was not embedded in other sites.

You should update your web server's configuration to set this header option, for example, in Apache2, you would:

<Directory /srv/ixpmanager/public>
    Header Set X-Frame-Options "DENY"
    ...

We have updated our automated installer script and our manual installation instructions to reflect this recommendation.

The report also mentioned Content Security Policy without going into detail. We have noted this for future work.

[VULN-03] User Enumeration via Differentiated HTTP Responses

It has been identified that certain web resources allow user enumeration by returning different HTTP responses depending on whether a user identifier exists in the application database.

After investigation, we determined that it is user ID enumeration (the auto-incrementing primary key), not user enumeration, and this was only possible for logged-in users. This has been corrected in this release.

[VULN-04] Information Disclosure – Error messages

In a particular error state, IXP Manager handled an exception by displaying the underlying SQL query. The penetration testers recognised that while IXP Manager is an open-source application and these queries are freely available, it would be more appropriate not to provide this information in a production environment.

This issue is corrected in this release.

New Features

Combined Peer-to-Peer Graphing

Users of IXP Manager's peer-to-peer (P2P) graphing functionality know that the graphs were not aggregated and could only be viewed on a per-IXP, per-protocol basis.

This release of IXP Manager introduces combined P2P graphs as the new default - your members will now be able to see all traffic exchanged with any peer over all infrastructures, ports and protocols, along with the ability to drill down to view these individually.

Along with the combined P2P statistics table in a previous release, our members will now have a much more informative, intuitive and useful view of their P2P traffic flows.

Support for bgpq4

We’ve officially added support for bgpq4 to IXP Manager, providing a modern alternative to the long-standing bgpq3 for generating IRRDB-based prefix filters. While bgpq3 has served the community well for years, bgpq4 is faster and actively maintained to handle the ever-increasing scale of global routing tables.

bgpq3 as a default is still maintained. To switch to bgpq4, which should be seamless, ensure you have it installed and either update the settings in the UI or edit the following in your .env:

# This can be either bgpq3 (default) or bgpq4:
IXP_IRRDB_UTILITY=bgpq4

# Path to bgpq4 utility - uses $PATH by default:
IXP_IRRDB_BGPQ4_PATH=bgpq4

Local ASN Resolution

When you click on AS numbers in IXP Manager, your browser makes an API call to IXP Manager which in turn made an API call to PeeringDB. This was often quite slow.

We now download and store bgp.tools' ASN Name export on a weekly basis. ASN lookups are now significantly faster. Thanks to @benjojo for this facility.

You can populate the database when you upgrade to v7.2.0 via:

./artisan utils:asn-update -v

Side Note: Laravel does not currently have a means to offset periodic tasks. I.e., we would not want ~260 instances of IXP Manager to download the CSV file at the same time (albeit load-balanced by time zone). In this release, we have implemented a custom jitter function for period tasks using a hash of the application key (APP_KEY in .env). This will randomise the job across IXP Manager installations, but keep it consistent within each installation.

A Word of Welcome to Our New Developer

We are delighted to introduce and welcome Thomas Kerin to the IXP Manager project as a full-time senior PHP developer.

Thomas is a seasoned PHP developer with over a decade of experience building robust, security-focused applications. After graduating from Trinity College Dublin with a degree in science, Thomas gained experience through several PHP development roles, which included leadership and security responsibilities. He has worked in diverse industries from educational startups to digital currency service providers.

Of particular note for our project, Thomas is well-versed in open-source software, best known for the Bitcoin-PHP project, as well as a number of other open-source PHP libraries and extensions in the security and cryptography space.

While Thomas only joined the project at the start of March, he has already jumped into fourth place with ~100 commits on GitHub’s contribut...

v7.1.0 Enhanced Security for Administrative Functions, and Much More

We are pleased to announce the immediate availability of IXP Manager v7.1.0. This is primarily a security update that enables IXP administrators to protect access to administrative functions at the web server level, thereby reducing the potential attack surface by 72%.

This release also includes bug fixes and many new features.

Release Summary

git --no-pager diff --shortstat v7.0.1 v7.1.0
 264 files changed, 11753 insertions(+), 5203 deletions(-)

Upgrade Instructions

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

NB: Before you disable maintenance mode, see the IPv6 max prefixes section below for how to check for inconsistencies.

---

New Features

Securing Administrative Functions

IXP Manager has always been both an administrative portal for organisations that run IXPs and a member/customer portal for the participants at an IXP. This creates a security paradox in that IXP Manager's administrative frontend must be publicly available if IXPs wish to provide the customer portal element.

To address this, v7.1.0 has prepended all administrative-only URLs, both web and API, with admin/. This will allow IXP administrators to restrict access to these prepended URLs to known-safe IP addresses via web server access lists, for which we provide examples for Varnish, Apache and Nginx here.

You can review the documentation here - https://docs.ixpmanager.org/7.1/install/security/.

Transition Settings

Prepending web requests with /admin should not cause any issues. However, IXPs that consume a number of the API endpoints may not be able to repoint them all to their newer /admin versions in a single maintenance window.

For this reason, IXP Manager v7.1.0 will ship with these API endpoints available under both /api/v4/... as before and also /admin/api/v4/.... Any requests to /api/v4/... will be logged, and these can be grepped as follows:

/srv/ixpmanager $ cat storage/logs/laravel.log | grep grep 'UNPREPENDED/DEPRECATED'
[2026-02-15 10:10:20] local.NOTICE: UNPREPENDED/DEPRECATED usage of API request api/v4/nagios/switches/2 from 127.0.0.1
[2026-02-15 10:27:01] local.NOTICE: UNPREPENDED/DEPRECATED usage of API request api/v4/router/gen-config/as112-cork-ipv4 from 127.0.0.1
[2026-02-15 10:27:07] local.NOTICE: UNPREPENDED/DEPRECATED usage of API request api/v4/router/gen-config/as112-lan1-ipv4 from 127.0.0.1

This default will be changed in the next minor release.

Once you transition the clients consuming the APIs from the unsecured endpoints (/api/v4) to the secured endpoints (/admin/api/v4), you can disable the unsecured endpoints ahead of the next minor release via the Authentication / Unsecured API Access Enabled checkbox on the Settings frontend, or by setting the following in your .env file:

UNSECURED_API_ACCESS=0

---

Router Configuration Improvements

Previous versions of IXP Manager shipped with individual sample route server, route collector and AS112 router (re)configuration scripts. However, these all essentially do the same thing, and in v7.1 we have merged them into this improved script - tools/runtime/outer-reconfigure-scripts/api-reconfigure-example-birdv2.sh.

Improvements include:

• new unified script to handle as112/collectors/servers
• new script releases lock via new API call on early exit
• added unit tests for the lock/release API calls
• database calls and database locking moved from model to controller for better testing

The documentation has been updated to reference and explain this new script, and we recommend you migrate to this new script, which, if you have not yet, will also implement lock/release for updates.

---

AS112

IXP Manager v7.1 includes an improved AS112 Bird2 template that now also utilises RPKI when available.

We are also releasing the templates for INEX's AS112 implementation with PowerDNS, as documented here. These are backed by a new testing framework in our Vagrant development environment and phpunit tests.

---

Route Server/Collector/AS112 Template Updates

The templates for the route servers, collectors and AS112 have been modernised to the latest BIRD 2 configuration standards since v2.14. There are no logic changes; it's essentially updating configuration elements, which modern BIRD v2 now warns about.

Examples include:

# old syntax
function filter_rpki()

# new with return type
function filter_rpki() -> bool

# old syntax with variable definitions outside filter
filter f_import_as65500
prefix set allnet;
ip set allips;
int set allas;
{

# new syntax
filter f_import_as65500
{
    prefix set allnet;
    ip set allips;
    int set allas;

# old syntax
password "foobar";

# new syntax includes mechanism
password "foobar";
authentication md5;

If you are running BIRD >= v2.14, you can update your templates by changing the router definitions as follows:

• Route servers: api/v4/router/server/bird2/standard -> api/v4/router/server/bird2-2025/standard
• Route collectors: api/v4/router/collector/bird2/standard -> api/v4/router/collector/bird2-2025/standard
• AS112: nothing required, the changes are in the standard template from IXP Manager v7.1.

Honour Graceful BGP Session Shutdown well-known BGP community (#960)

The above templates also include this from @job:

BCP 214, section 3.1.1, suggests using the well-known GRACEFUL_SHUTDOWN BGP community [RFC8326] to facilitate smooth drainage of traffic prior to BGP session tear down. The goal is to reduce or avoid packet loss for outbound and inbound traffic flows initially forwarded along the peering link planned to be shut down.

With this routing policy change, Route Servers will preemptively converge onto alternative paths (provided those exist), or just continue to use the marked path until it is withdrawn. In other words, this implements a form of "make before break".

Even when no alternative paths exist in the Route Server's Loc-RIB itself, it is beneficial to promote the use of this BGP community, because its presence allows the RS peers (which hopefully /do/ have alternative paths!) to preemptively converge.

---

Introduction of IPv6 Max Prefix Settings

As requested in #937, we now introduce a new IPv6 max prefix setting so that different values can be entered for ipv4 and ipv6, as these tend to vary wildly.

NB: The IPv6 max prefix values will be initialised to the current IPv4 setting during the migration, as these were used for both.

As a reminder, the value for maxc prefixes is determined as follows:

The ipv4/6 max prefix setting on the customer is known as the global max prefixes value. It is used to work out the appropriate max prefixes value to apply to all router ipv4/ipv6 configurations in the stock / default templates (route collector and servers, AS112). The calculated value is also included in emails from the Peering Manager from customer to customer.

It is also possible to set a max prefixes value on a per VLAN interface basis. This should be avoided unless it is something you need to do.

The max prefixes value is worked out in the code when generating router configuration is as follows:

1. The the VLAN interface value if set, otherwise the global value as set on the customer as above
2. If neither is set, a default value is used (this can be changed in the Settings UI or the .env file).

The defaults can be updated in the Settings frontend, or via the following (defaults shown) in your .env:

IXP_DEFAULT_MAXPREFIXES_V4=250
IXP_DEFAULT_MAXPREFIXES_V6=50

During the upgrade process, you should check for max prefix inconsistencies as the evaluation has changed if a value was set on the customer and on a vlan interface:

• Before v7.1: the greater of the two.
• From v7.1: the value on the vlan interface.

Run the following artisan command:

$ php ./artisan update:max-prefixes-7.1.0

In IXP Manager v7.1, we have made some changes to how max prefixes is handled. In previous
versions, a max prefixes setting on a VLAN interface only took effect if it was greater than
the global (as set on the customer) value.

This is not intuitive as we should allow the more specific setting on the VLAN interface, whether
lower or higher than the global, take precedence.

This script will identify any settings on VLAN interfaces that are lower than the global setting,
as these will start to take effect, and give you the option to clear the setting.

This tool will walk you through any inconsistencies and ask you to make a decision on what do with each.

---

RPKI

RPKI RTR Version Settings in BIRD

BIRD has the following RPKI RTR settings:

min version num

    Minimal allowed version of the RTR protocol. BIRD will refuse to downgrade a 
    connection below this version and drop the session instead. Default: 0

max version num

    Maximal allowed version of the RTR protocol. BIRD will start with this version. 
    Use this option if sending version 2 to your cache causes problems. Default: 2 

To allow you to set these without skinning the templates, there are new s...

v7.0.1 - Post-Release Fixes for v7.0.0.

INEX installed v7.0.0 in production during a maintenance window earlier this week, and we observed a small number of issues that are corrected in this release.

All UI and unit testing have passed for this release details in 53cf8f8.

Improvements and Fixes Relating to v7.0.0

• [UI] Some typo fixes where contributed in #939, which prompted a more thorough review in ed795f2.
• [BF] The dotEnv parser needs to treat zero and one as ints and not bools. If they need an interpretation as bool values, the phpDotEnv parser will take care of that 9b92b3c.
  • Recommended Action: if you saved your configuration via the new UI settings page, check for anything that should be 0 or 1 which will have been incorrectly replaced with false or true respectively, and manually edit your .env to change these back.
• [BF] Incorrect config keys for PeeringDB OAuth settings within the new settings UI 317b9c1. No action required, as this would not affect existing values in .env files.
• [BF] Inverted checkboxes in the new settings UI did not accept changes e5b0efd. No action required, as this would simply not have allowed a change and mostly affected enabling / disabling frontend components.
• [BF] A logic error in the left-hand side menu hide the IRRDB Configuration menu item 9c887fc.
• [IM] Revert changes to Bird2 route collector config, as it contained some syntax that is incompatible with older versions of Bird2 10a30b1. This also introduces a new, second Bird2 template for use with more modern versions of Bird2, designed explicitly for route collectors.
  • The new template is api/v4/router/collector/bird2-2025/standard and it is included in new unit testing.
  • Recommended Action: if you upgraded to v7.0.0, and used the route collector templates without issue, you are most likely running a version of Bird2 >= 2.14. In this case, you can safely change the template for the route collectors to the new template above.
  • Route server and AS112 template improvements will follow in later versions of IXP Manager in this way.
• [BF] Fix to the physical interface diagnostic test suite which accessed an incorrectly named database row for the port speed 92b9c6a.
• Third-party packages have been updated.

Other Improvements and Fixes

• [HK] File housekeeping - some old files were removed, and others were rearranged 7d0610f.
• [HK] The master branch was renamed to main, and various links were updated 3ebe888.
• [UI|BF] The looking glass generated a JavaScript error when the BGP summary table was empty 196807e.

Upgrade Instructions

We have yet to document specific upgrade instructions within the v7.x.y release tree. In the meantime, the instructions for upgrading within the v6 release tree can be used, replacing v6.x.y in step 3 with v7.0.1. As v7.0.1 release does not include any database migrations, steps 6 and 11 can be safely skipped.

v7.0.0

IXP Manager v7 (v7.0.0)

We are pleased to announce the immediate availability of IXP Manager v7.0.0. This is a major upgrade of the underlying Laravel framework and introduces a new required PHP version of v8.4. We recognise that mandating a new PHP version is a significant change for our users and often requires an underlying operating system upgrade. However, the technologies on which v6.x is built have passed their end-of-support and security maintenance periods.

IXP Manager v7 is now built using:

• PHP v8.4, which will be supported by the PHP core team for security updates until the end of 2028.
• The latest version of the Laravel Framework, 12.x. In addition, its upcoming 13.x version will also be compatible with PHP 8.4 and provide support until at least Q1 2028.
• All third-party PHP libraries and frontend JavaScript libraries have also been updated.

We've included detailed upgrade instructions below, including a video by @barryo.

Release Summary

git --no-pager diff --shortstat release-v6 release-v7
 696 files changed, 76639 insertions(+), 56310 deletions(-)

A summary of the most significant changes in IXP Manager v7 includes:

• Underlying framework and third-party library updates as mentioned above.
• The introduction of static code analysis into our CI pipeline.
• A new Diagnostics Suite feature to significantly speed up troubleshooting member issues.
• P2P Graph Sorting.
• Various IRRDB Enhancements.
• Database logging of IRRDB updates.
• Configuration via a new frontend UI.
• Versioned documentation.
• Additional unit tests, including near-complete frontend coverage.
• A Vagrant development environment.

Acknowledgements

László Kiss (@griphons) joined the IXP Manager core team from March 2024 to April 2025, making a significant contribution to IXP Manager v7. Moreover, some additional features he was working on are largely complete but not production-ready and will be held back for a future release. We thank László for his contributions.

Bringing on developers such as László would not be possible without our sponsors. In addition to INEX, several IXPs sponsored the development of v7, including NIX, BCIX, INX-ZA, LONAP, INTERLAN, NAMEX and GRIX. We also had two patrons, ISOC and APNIC Foundation. The APNIC Foundation deserves special mention as our only diamond patron.

See https://www.ixpmanager.org/sponsors for more information on how to sponsor the project.

Talks About IXP Manager v7

We have already provided updates on IXP Manager v7 at several conferences, including RIPE 89 and the 41st Euro-IX Forum. You can find the presentations and, where available, links to videos at https://www.ixpmanager.org/support/talks.

NB: In these pre-release talks, we were targeting PHP 8.3/Laravel 11 as our release target. These have since been updated to PHP 8.4/Laravel 12.

New Features

IRRDB Enhancements

The possibility of IRRDB updates failing silently was raised in #877, and this has been addressed in several ways; all documented in the updated page at https://docs.ixpmanager.org/7.0/features/irrdb/.

The primary change to alert administrators of an issue is that an email is now sent to the configured IDENTITY_ALERTS_EMAIL recipient. This defaults to IDENTITY_SUPPORT_EMAIL, and so alerts should work once v7.0.0 is installed.

Several additional features have also been added relating to the IRRDB database management:

1. The new IRRDB Summary (left-hand side menu) provides a summary of all members' IRRDB database entries/status. This menu highlights members for whom there has never been an IRRDB update (usually new members or members for whom the process has failed) and highlights as stale any member whose entries have not been updated in the last 24 hours.
2. The last time a member's IRRDB entries were updated is also shown on their overview page.
3. A member's IRRDB entry status can be checked using the new diagnostics functionality.
4. You can click through from many places to view and update a member's IRRDB entries:
   • Via the summary page above in (1);
   • Via the IRRDB information on the member's overview page in (2); and
   • Via a menu option on the member's overview page.

Peer-to-Peer Graph Sorting

When IXP Manager introduced peer-to-peer (p2p) graphs, they quickly became the most popular feature for end users and the typical driver for them to log into the portal routinely. However, scrolling through tens or even hundreds of graphs that are neither sorted nor y-axis aligned is not an efficient or helpful way to identify a network's "top ten peers" or traffic anomalies. While the ultimate goal is to use a time-series database, as a stop-gap measure, we are introducing a new feature in v7 to order a member's p2p graphs by volume.

This will be enabled by default if your GRAPHER_BACKEND_SFLOW_ENABLED setting is on. I.e. if you are already using IXP Manager's p2p functionality, then this will "just work" when you upgrade to v7 via the task scheduler.

If you want to give it a kick start, run the following with yesterday's date:

./artisan grapher:upload-daily-p2p -v YYYY-MM-DD

More information can be found here in the documentation.

Frontend Configuration

Traditionally, applications using the Laravel framework are configured via a .env file in the root directory of the web application. This requires server access to make even minor changes, and even then, it is a large and complex file. Moreover, as IXPs upgrade IXP Manager in situ, they may often forget to add new configuration options in newer releases, even if only using the defaults for documentation purposes.

In IXP Manager v7, we introduce a new Settings component, accessible from the bottom left menu under IXP UTILITIES. Most common settings can now be viewed and changed here.

When you access this new feature for the first time, it will run several checks to ensure that the .env file is writable by the web server process, and that your existing .env file is compatible. More details can be found in the documentation.

Versioned Documentation

As each release adds features, we recognise that the documentation can become confusing when it is not clear when a feature was introduced.

To resolve this, we have now started versioning the documentation. When you browse to https://docs.ixpmanager.org/, you will be redirected to https://docs.ixpmanager.org/latest/ by default. 'latest' will always reference the last released major.minor version. As of now, v7.0 is the latest release, and so https://docs.ixpmanager.org/latest/ will provide the 7.0 documentation.

All new documentation will be added to the 'dev' identifier - https://docs.ixpmanager.org/dev/ - which currently points to 7.1 in preparation for that release.

All links within IXP Manager have been updated to reference the /latest documentation now.

Member Diagnostics Suite

This release includes an early proof-of-concept implementation of a work in progress to ease the support burden of supporting member connections. In the tools (gear icon) menu on customer overview pages, there is a new Run diagnostics... command. This will run a suite of tests, including:

• Customer/member set-up validation;
• IRRDB tests (database populated, entries fresh, etc.) for customers with IRRDB filtering;
• Virtual interface tests;
• Physical interface tests (including snmp tests to see if the port is up or down, to check MTU, speed, etc.);
• Route BGP tests for route server, route collector, and AS112 session status where the Birdseye looking glass is available; and
• Transceiver rx/tx power tests, where supported.

Future iterations on this feature will include UI/UX review and connectivity tests, such as ARP and ping replies.

Security Information and Updates

Secure Application Development Policy

As cybersecurity becomes more regulated through legislation such as the CRA and NIS2, users of IXP Manager must review, risk assess, and document their use of third-party software and supply-chain security. We recognise that IXP Manager is a key element of that for many IXPs.

INEX has been ISO 27001:2022 Information Security Management System (ISMS) certified since 2023, and the further development of IXP Manager is within the scope of INEX's ISMS Secure Application Development Policy. This includes the review and merging of contributions from third parties.

The IXP Manager project has now published its secure application development policy and our long-standing security policy.

2FA Now Enforced for All Users by Default

Continuing to consider the current cybersecurity environment and best practices, new installations of IXP Manager will enforce 2FA for all users by default.

In previous versions, it was an optional measure that users could elect to use. To restore this behaviour, you can set the following .env variable (or use the new Settings UI):

2FA_IXPM_ENFORCE_FOR_USERS="4"

At a minimum, we strongly suggest and recommend requiring 2FA for admin and customer admin users via:

2FA_IXPM_ENFORCE_FOR_USERS="2"

Continuous Integration (CI)

IXP Manager grew out of a code base and schema that started in the early '90s. Long before [test-driven deve...

v6.4.2 - Maintenance Release

We are pleased to announce the immediate availability of IXP Manager v6.4.2.

This is a maintenance release for the v6 branch and includes a bug fix and third-party library updates.

Sunsetting v6

IXP Manager v6 is now in a sunset state. The underlying technologies (PHP 8.0 and Laravel v9) have also reached end-of-life. We will continue to release updates to address any security issues until at least v7 is released and announced as stable. We plan to release IXP Manager v7 before the end of 2024. You can see slides and videos from two recent talks we made introducing IXP Manager on the talks page here.

Release Summary

❯ git --no-pager diff --shortstat v6.4.1 release-v6
 31 files changed, 5276 insertions(+), 3646 deletions(-)

Upgrade Instructions

The official upgrade instructions can be found here.

🚨 Upgrade to v6.4.0 first following those release notes.

The changes in this release are small improvements and bug fixes. Upgrading should be straightforward.

Improvements

• Full update of third-party libraries (composer for PHP, npm for frontend assets).
• MANRS updated their API endpoints recently, removing the API target IXP Manager used to identify if members were MANRS compliant. This has been updated to use their new API.
• Minor other changes.

v6.4.1 - Polishing v6.4.0

Ten IXPs have upgraded since we released v6.4.0 just over two weeks ago. Thanks to all of them for their feedback and bug reports - especially Ed, Moritz and Nishal. v6.4.1 reflects their contributions and can be considered a polished, stable, production-ready release.

Release Summary

git --no-pager diff --shortstat v6.4.0 release-v6
 17 files changed, 802 insertions(+), 724 deletions(-)

Upgrade Instructions

The official upgrade instructions can be found here.

🚨 Upgrade to v6.4.0 first following those release notes.

The changes in this release as small improvements and bug fixes. There is one database migration to reset the MySQL VIEWs which does not affect IXP Manager's production use. Upgrading should be straight-forward.

Bug Fixes

• [BF] artisan utils:smtp-mail-test failed as it was referencing Laravel's older and now removed mail library 8473497
• [IM] Telescope caused issues due to excessive undefined array element logging when running under PHP 8.1. Telescope is typically used more as a development aid rather than a production tool and should be disabled by default 6342226
• [DB] While not required for IXP Manager, we maintain the older views as we know some people have integrated their own scripts into using them. The script to refresh these now relies on changes later in the migration path and so we have moved the migration for the view reset. Fixes #894.
• [BF] IXP Manager's PeeringDB interface has changed which broke the PeeringDB helper when adding new members - 7a4e41c
• The verbose warnings under PHP 8.1 for non-IXP Manager library code was raising some queries on the mailing list. Found a way to silence these via a dummy logging driver entry b083dff

v6.4.0 Route Servers - Resilience and UI Based Community Filtering

This release provides significant new features for route server resilience, UI-based community filtering, and many smaller improvements and bug fixes.

Release Summary

git --no-pager diff --shortstat v6.3.1 master
 218 files changed, 21503 insertions(+), 28569 deletions(-)

Upgrade Instructions

🚨 🎥 There is a tutorial video demonstrating this upgrade including all the required changes on route collectors and route servers available on YouTube here.

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

Edit your .env file and add the following:

TELESCOPE_ENABLED=false

Once that is complete, and assuming you have read these release notes in full, proceed as follows:

1. Edit your router definitions on IXP Manager to set up router pairs.
2. Replace your route server and route collector update scripts with the new scripts linked below.
3. Update the cadence of the router update scripts and enable the route server filtering UI.

Route Server Resiliency

For IXPs, route servers are considered a critical production service and most IXPs deploy them in redundant pairs. This is usually implemented with dedicated hardware (servers with dual PSU, hardware RAID, and out-of-band management access) deployed in different points of presence.

When it comes to updating the configuration of these, the scripts provided by IXP Manager suggested that this be done about four times per day with the timing of the cronjob set so that there is an offset so that each server will not update at the same time. The hope was that if there was an issue, only one server of the resilient pair would be affected, and engineers would have time to react and prevent updates on the other working server. Some IXPs added additional logic to the scripts to check if the other server was functional before performing a reconfiguration, but this was often limited to pings and a simple check to see if Bird was running.

This release adds a significant new resilience mechanism by pairing servers. In the IXP Manager router UI, you can now select another router to pair with the one you are editing. You would select pairs as follows:

• For route servers deployed in pairs, rs1-ipv4 should be paired with rs2-ipv4 and vice versa - be sure to set the paired server in each individual server.
• For route collectors, quarantine route collectors and AS112 services where you would normally have a single instance, you can pair the ipv4 version with the ipv6 version, ensuring at least one will always be running. For example, pair rc1-ipv4 with rc1-ipv6 and vice versa.

Once your pairs are set up, you need to deploy the new router update scripts as follows:

• for route servers: tools/runtime/route-servers/api-reconfigure-example-birdv2.sh
• for route collectors: tools/runtime/route-collectors/reconfigure-rc-bird2.sh

There is no need to use different scripts for route collectors and servers. Traditionally, at INEX, these scripts were developed slightly differently from each other (e.g., the collector script updates both IPv4 and IPv6 versions and provides more informative output, whereas the route server script takes a specific route server handle to update). We may merge these in the future.

You can use these scripts exactly as they are on an Ubuntu server changing only the configuration lines at the top:

APIKEY="your-api-key"
URLROOT="https://ixp.example.com"
BIRDBIN="/usr/sbin/bird"

The collector script takes an additional configuration option for the handles of the servers to update - e.g.:

HANDLES="rc1-ipv4 rc1-ipv6"

These new scripts now work as follows:

1. NEW: Obtain a local script lock preventing more than one update script to execute at a time.
2. NEW: Obtain a configuration lock from IXP Manager.
   • This involves making an API call to /api/v4/router/get-update-lock/$handle, which IXP Manager then processes and returns HTTP code 200 if the lock is acquired and the update can proceed.
   • A lock is not granted if the router is paused for updates within IXP Manager (new per-router option in the router's dropdown menu on the router list page).
   • A lock is not granted if another process has already acquired a configuration lock for this router.
   • A lock is also not granted if the router's partner is locked. This major new resiliency addition prevents two paired route servers from being updated in parallel.
   • The update script will be aborted if IXP Manager is unavailable or in maintenance mode.
3. If a lock is acquired, the script will then download the latest configuration from IXP Manager.
4. The script will do some basic sanity checks on the downloaded configuration:
   • First, check that the HTTP request to pull the new configuration succeeded.
   • Second, check that the downloaded file exists and is non-zero in size.
   • Third, ensure at least two BGP protocol definitions are in the configuration file.
   • Lastly, the script has Bird parse the downloaded file to ensure validity.
5. NEW: The update script will now compare the newly downloaded script to the running configuration.
   • If there are differences, the old configuration is backed up, and the Bird daemon will be reloaded.
   • If no differences exist, the Bird daemon will not be reloaded.
6. A check is performed to ensure the Bird daemon is actually running and, if not, it is started.
7. IMPROVED: A final API call is made to IXP Manager via /api/v4/router/updated/$handle to release the lock and update the timestamp.
   • A significant improvement here is the use of a until api-succeeds, sleep 60, retry construct to ensure the lock is released even when there are transitive network issues / IXP Manager maintenance modes / server maintenance, etc.

Adding step (5) above (only reload on changes) now allows the update script to be safely run as frequently as every few minutes, which is necessary for the UI-based community filtering to be effective.

You should still offset the updates between router pairs, as the script will give up if a lock cannot be obtained. Future improvements could allow for some retries.

For additional information with UI images, see slides 25-30 in this presentation PDF.

Route Server Community Filtering via the UI

Community-based filtering is the standard way to allow route server participants at an IXP to control their routing policy. IXP Manager has supported - and set - the standard across the industry since route servers were introduced at INEX in 2007.

Such filtering is essential to maximise participation with route servers as the member is essentially outsourcing their routing policy to the IXP, and many would be uncomfortable or unable to do this without these basic controls.

Community-based filtering in practice can be difficult for participants at both ends of the network-size scale:

• Small networks rarely touch their border routers and may be both unfamiliar and uncomfortable with the necessary concepts and configuration to use them. This is especially true in a stressful situation when they urgently need to apply communities for the first time.
• Large networks may need cumbersome change control procedures or, in some cases, their automated provisioning pipeline may not even support them.

We must also remember that community filtering is only half the story - the participant will still need to apply route filters to the routes they learn from the route servers (community filtering applies to how their prefixes are propagated by the route servers).

This release of IXP Manager introduces a new feature which allows IXP members to configure route server filtering in a web-based UI. This will move the configuration complexity from the member and their router to the IXP's route servers. The actual mechanism of filtering is unchanged - just where it happens moves:

• The route server will apply community tags to the member's routes immediately at ingress rather than the member doing it on
  egress.
• In the other direction, the route server will filter routes to be advertised to the member on egress rather than the member doing it on ingress.

We expect this to work for >=90% of use cases. A member with a more complex routing policy should handle it on their own routers anyway.

The implementation in IXP Manager uses two database tables - a staging table and a production table. When a member first creates or subsequently edits their filters, this will happen in the staging table. Once they are satisfied their routing intentions are complete, they can commit the changes to the production table. As each router processes its next configuration update, the comparison diff discussed in the above section will show differences, and the router configuration will be updated. It is important, therefore, to have the route servers update on a schedule of at least every 10 minutes.

To allow IXP administrators to update and increase the frequency of their route server update scripts, this UI feature is disabled by default. To enabled it, add the following to your .env file:

IXP_FE...

XSS Security Fixes, Small Bug Fixes and Minor Improvements

This release primarily fixes a number of XSS security issues in IXP Manager. These were discovered and responsibly disclosed by the GRNET IT Security Team and we thank them for that.

This release is a bugfix release and so there are no database schema changes.

Summary:

Release Summary

git --no-pager diff --shortstat v6.3.0 v6.3.1
 78 files changed, 1390 insertions(+), 1155 deletions(-)

Upgrade Instructions

The official upgrade instructions can be found here.

The changes in this release as small improvements and bug fixes. There are no database changes or other complexities. Upgrading should be straight-forward.

Security Fixes

This release includes a fix for five XSS security bugs.

We judge four of these bugs have a CVSS score of CVSS:0.0/AV:N/AC:L/PR:H/UI:R/S:U/C:N/I:N/A:N. These can only be exploited by an authenticated superadmin user who would enter specifically crafted JavaScript code in specific input fields.

The final we judge as CVSS:4.6/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:L as an attack exploiting this could be possible from a sufficiently sophisticated and motivated non-admin user who could find a way to inject a XSS payload into a logged database object and could then convince a superadmin to view that database change in the UI log tool. The GRNET IT Security Team have registered CVE-2023-36666 for this.

Credit to the GRNET IT Security Team for responsibly disclosing these issues.

Improvements

• Composer will install the latest OSS_SNMP library making more switches compatible with IXP Manager.
• All PHP framework and libraries used have been updated to latest versions as compatible with PHP 8.0.
• [NF] Filter by ports prewired only in patch panel management 844e16a; closes #814
• missing lladdr ignore no longer available in bird2 - removed from templates b81b89c
• Route server config for bird2 now fixed to allow 32-bit asns via 493ba15)

Bug Fixes

• Ignore reseller ports when generting MRTG configuration via e40be75; closes #855

v6.3.0 - Security hardening, with various improvements and bug fixes

A commercial IT consultancy provider uses IXP Manager in one of their solutions. They had their overall solution reviewed by an internationally respected cyber security and risk assessor. This review included IXP Manager and the commercial IT consultancy responsibly disclosed all of the issues and advice related to IXP Manager.

These have been addressed in this release and are itemised below. We recommend all IXPs that use IXP Manager upgrade to this new version.

We thank the IT consultancy, and those within it that we have been dealing with, for sharing the findings with us.

Release Summary

$  git --no-pager diff --shortstat v6.2.0 release-v6
 87 files changed, 3025 insertions(+), 2513 deletions(-)

Upgrade Instructions

The official upgrade instructions can be found here.

This release does include some minor database migrations - please follow the instructions above.

Post-Upgrade Instructions

We use Laravel's mail system and so we need to keep in sync with their defaults. A recent change means that when sending email via SMTP, tls no longer the default. See #752 for a discussion.

If using SMTP, ensure you test emails via the test tool here.

Security

• Remove web.config from public via e9d0819. Not used and was the framework default so not an issue here, just best practice. Came up as an issue in a security audit and we note this has been removed from Laravel for the same reason: laravel/laravel@4bc502b
• Escape specific instance of HTML content to prevent XSS [ref: 055-9-4] via bc9b14c
• Make response to forgotten password generic [ref: 055-9-8] via 04fe7d8
• Implement a stronger password policy [ref: 055-9-7] via 2889be9
• Prevent XSS / JS interpretation in preview boxes [ref: 555-9-9] via 083d17e
• Disable phpinfo() by default [ref: 055-9-11] via 921f515
• Don't allow user with priv = 0 [ref: 055-9-13] (bug fix) via e5a48ab
• Check for patch panels when deleting racks [ref: 055-9-14] via 5ec406e

Improvements

• Peering Matrix - increase look-back days and make configurable which makes the detection better in some cases via 53333e4
• Garbage collection for macaddress table via 724a05c
• Make member display name formatting configurable in .env to assist with #766
• Preserve IXPM functionality from recent OSS_SNMP change via 1b4cbfa re switch serial number via SNMP being not implemented
• Remove final runtime dependency on views.sql via b414ca1
• Modernise PeeringDB and IX-F links and make them configurable via 0ac782d
• Add patch_panel.colo_pp_type - a new database for the colo end of patch panels via 3fd45df
• Link to reseller in member overview. Use more commonly displayed abbreviatedName. Closes #802
• Update robots.txt - LG can also be referenced using /index.php/lg/. Need to exclude this from search engines via 4e17563
• Enable logout on 2fa required page - fixes #806 and prevents user getting 'locked' in 2fa

Bug Fixes

• Fix display of IPv6 addresses in mac-address/list via d37e285
• Fix duplicated entries in mac-address/list route via daee524
• $sp->isTypePeering() -> $sp->typePeering() via 305a79e
• Could not save associate member edits due to int/string comparison via b707e00
• Fix issue with route display in looking glass via 5f7b338
• Fixing vlan id to close #773
• Incorrect ipv6enabled check - noted by @listerr in #778 - and also bugfix via d1278d5
• ipv4_subnet does not display properly - fixes #783
• Core bundles - need user before checking for permissions via 66d1a60
• Escape returned data and error messages on login forms via c623390
• /statistics/member raises error if not auth'd via f9d2f99
• Fix log viewer - do not crash out if user is deleted / not listed on log via 2ab9102