We are excited to announce the latest updates and enhancements to our platform.
This release refreshes the FABRIC user experience with Portal updates and a new public website, improves experiment planning through resource calendar and slot discovery, hardens the testbed with a full security and software stack update across every site, and modernizes the underlying platform with an upgrade of the FABRIC Control Framework to release 2.0.0.
Key Updates
New Public Website: whatisfabric.net
- FABRIC’s public-facing website has been refreshed at whatisfabric.net,
organized around what you can build on the testbed: prototyping novel network
and computing solutions, connecting to NSF clouds, ACCESS clusters, and campus
infrastructure, and programmable control of advanced hardware. - Events and workshops, project highlights, news, and live testbed statistics are
now brought together in one place, with direct links into the Knowledge Base
and the Portal.
Portal Updates
- The Portal UI has been refreshed to align with FABRIC 2.0 branding — updated theme colors, typography and component styling now mirror the new marketing site at whatisfabric.net.
- About and Community static pages have been migrated to whatisfabric.net. Portal navigation bar links now point to the new site for these sections.
Security and System Updates Across All Sites
- All FABRIC systems have been patched and updated in response to the recent increase in security vulnerabilities being discovered by advanced AI tools. Keeping the testbed current on these fixes was the priority driving the August 3-7, 2026 maintenance window.
- Operating system and security patches were applied across site head nodes, workers, and management services at every site.
Resource Calendar and Slot Discovery
- A new resource calendar and find-slot capability lets you see when the resources you need are available before submitting a request, reducing failed reservations when planning experiments.
- Aggregate capacity information can now be exported for planning and reporting.
Improved Slice Lifecycle Reliability
- Slices no longer become stuck in the Configuring state when a site does not respond to an extend or modify request.
- Stuck slice status and reservation state handling have been corrected, so slice state now reflects actual reservation state more reliably.
- The orchestrator no longer sends broker requests to a site Aggregate Manager
after a restart.
Platform Modernization
- All Control Framework and Aggregate Manager containers now run Python 3.13.
- PostgreSQL and Neo4j have been updated, along with the cryptography library, and resource query handling has been improved.
- Site Aggregate Manager handlers were upgraded to Ansible 13.6, and a retry-loop off-by-one error in resource delete was fixed.
Packages and Components
Control Framework (Orchestrator, Broker, Site Aggregate Manager) – 2.0.0
- Resource calendar proxy, find-slot endpoint, and capacity export
- Slice status and reservation state handling fixes
- Orchestrator broker-request routing fix after restart
- application/json mimetype set on CORS responses
- Python 3.13, updated PostgreSQL and Neo4j, updated cryptography
Site Aggregate Manager Handlers – 2.0.0
- Ansible 13.6 and Python 3.13
- Retry-loop off-by-one fix in resource delete
Platform Components
- Python: 3.13
- Ansible: 13.6
- PostgreSQL: 17.7
- Neo4j: 5.26 (with APOC)
- AuthZForce PDP: 6.1
FABRIC Core API v1.11.2 — Release Summary
Tagged 162c9df on main, 2026-08-05. Deployed 1.10.0 → 1.11.2 on alpha-6 (08-05), beta-3 (08-06), and uis production (08-07). Since every host jumped straight from 1.10.0, this summarizes the cumulative 1.10.0 → 1.11.2 delta (14 commits, 11 PRs, spanning point releases 1.11.0 / 1.11.1 / 1.11.2).
API surface is unchanged at 71 operations. No endpoints added, removed, or renamed.
Security fixes
Anonymous private-project disclosure (#174). The anonymous branch of GET /projects/{uuid} had no is_public check, so an unauthenticated caller received name, description, communities, project_funding, fabric_matrix, and project_type for any project — strictly more than a signed-in non-member, who already got a 403 for the same condition. The guard now mirrors the authenticated branch. GET /projects (collection) was already safe; this was specific to the detail endpoint. Live in production prior to the fix.
Internal errors no longer echo exception text (#174) — client-visible wire change. cors_500 now renders the constant An internal server error occurred. in both the response body details and the X-Error header. Previously it passed str(exc) straight through, which could carry SQL, bound parameters, and control characters from SQLAlchemy/driver strings. Any consumer or operator tooling that parsed diagnostic text out of a 500 body or X-Error now gets a constant. Diagnostics are not lost — they moved to consoleLogger.error.
NUL rejected at the spec layer (#174). pattern: ‘^[^\x00]*$’ on the announcements search parameter, so a NUL-bearing request 400s before reaching the driver.
Werkzeug debugger path removed (#150). The dev entrypoint hardcoded app.run(debug=True); it now reads FLASK_DEBUG (default false), closing the only path that could expose the Werkzeug debugger (GHSA-2g68-c3qc-8985, RCE). Production runs uWSGI and was never affected.
Dependency CVEs: joserfc 1.6.4 → 1.7.3 (GHSA-gg9x-qcx2-xmrh high — HS256/384/512 verification accepted an empty/nil HMAC key; GHSA-wphv-vfrh-23q5 moderate — b64=false JWS payload-size bypass), mako 1.3.11 → 1.3.12 (GHSA-2h4p-vjrc-8xpq high — path traversal in TemplateLookup), cryptography 47.0.0 → 50.0.0 (CVE-2026-69247). Also authlib 1.7.0 → 1.7.1, pyjwt 2.12.1 → 2.13.0, urllib3 2.6.3 → 2.7.0, idna 3.13 → 3.15.
Known residual: connexion 2.14.2 pins werkzeug<2.3 and flask<2.3 while the patched releases are 2.3.8+/3.1.3, so the remaining Werkzeug and Flask alerts are structurally unfixable on the 1.x stack. They are dismissed with per-alert justifications and close with the v2 framework cutover.
Features
infrastructure project type (#169). New enum member on project_type for both POST /projects and PATCH /projects/{uuid}.
The facility-operator requirement is now consolidated in project_type_requires_facility_operator() and covers {industry, infrastructure, maintenance, service}. Behavior change: that gate was previously enforced only on PATCH — POST /projects now returns 400 when a non-facility-operator requests one of those types. Relatedly, project creation honors the requested body.project_type instead of hardcoding research, and default: research was dropped from the POST schema.