Recent research has highlighted active attacks against two widely used open-source platforms: MLflow, a machine learning lifecycle tool, and FUXA, a web-based SCADA/HMI solution for industrial automation. Of particular concern to state and local governments, school districts, and community-serving organizations is an MLflow server-side request forgery (SSRF) vulnerability that can expose cloud credentials and secrets.
For public-sector teams increasingly adopting AI, cloud platforms, and operational technology (OT) integrations, these findings are a reminder that open-source components must be managed with the same rigor as commercial products. Vulnerabilities in supporting tools can compromise protected health information, student data, public safety systems, and the accessibility of critical online services.
Key Takeaways
- Attackers are actively scanning for and exploiting critical vulnerabilities in MLflow and FUXA.
- An SSRF flaw in MLflow can allow remote attackers to access internal services, cloud metadata endpoints, and stored secrets.
- Compromised secrets can lead to broader cloud account takeover, data exfiltration, and disruption of public-facing and internal services.
- Open-source AI and OT tools need structured governance, patching processes, and configuration baselines in public-sector environments.
- Public agencies should align remediation with accessibility, continuity of operations, and security policies to protect residents and staff.
What Is MLflow and Why It Matters for Public-Sector Teams
MLflow is an open-source platform that helps organizations manage the lifecycle of machine learning models, including:
- Experiment tracking and versioning
- Packaging models for deployment
- Managing model registries
- Integrating with cloud platforms and storage
Agencies and education institutions may use MLflow—or similar tooling—as part of:
- Data science environments for research, student analytics, or fraud/waste detection
- AI/ML pilots supporting case management, traffic analysis, or resource allocation
- Internal innovation labs that blend open-source tools with commercial cloud services
Because MLflow often runs in cloud or hybrid environments and has access to data repositories, model artifacts, and credentials, any compromise can have outsized impact on security, privacy, and service continuity.
Understanding the MLflow SSRF Vulnerability
What Is SSRF?
Server-side request forgery (SSRF) is a class of vulnerability where an attacker can trick a server into making HTTP requests on their behalf. Instead of directly accessing a sensitive resource, the attacker abuses a trusted internal system to reach:
- Internal-only endpoints (e.g., internal APIs, databases, or control planes)
- Cloud provider metadata services (which often expose credentials or tokens)
- Other network services not intended to be public
In cloud environments, exploiting SSRF against the metadata service can allow attackers to retrieve temporary credentials, then use those credentials to access storage, databases, message queues, or other platform resources.
How Attackers Can Abuse MLflow
Independent security research has identified an SSRF flaw in certain configurations of MLflow. When exposed to the internet without proper controls, this weakness can allow an unauthenticated or minimally authenticated attacker to:
- Trigger MLflow to send HTTP requests to arbitrary URLs
- Target internal addresses that are otherwise unreachable from the public internet
- Query cloud metadata endpoints to retrieve access keys, tokens, or instance identity information
- Harvest secrets such as API keys, database credentials, and storage access tokens
Once an attacker obtains valid cloud credentials, they may pivot into:
- Reading or modifying data in object storage, databases, or data lakes
- Creating or changing cloud resources in ways that impact operations
- Deploying additional backdoors or cryptomining workloads
- Disabling logging and monitoring to evade detection
For public-sector deployments, the indirect impact is often more significant than the initial flaw. The main risk is not simply losing control of the MLflow server; it is the compromise of the broader cloud account or on-premise environment it can reach.
FUXA and Risks to Operational Technology
FUXA is an open-source, web-based SCADA/HMI platform used to design and control industrial and OT environments. It can connect to programmable logic controllers (PLCs), field devices, and other automation systems.
The reported FUXA vulnerabilities show that attackers are equally interested in platforms bridging IT and OT. For municipalities, transit agencies, water and wastewater systems, and school facilities, weaknesses in web-based SCADA/HMI tools can translate into:
- Unauthorized access to building automation, utilities, or environmental controls
- Potential manipulation of setpoints or alarms
- Loss of visibility into critical infrastructure status
While the technical details differ from the MLflow SSRF flaw, both cases underscore the need for strong security architecture, segmentation, and governance around any web-accessible control panels or dashboards.
Public-Sector Impact: Security, Accessibility, and Service Continuity
For agencies and education institutions, vulnerabilities like those in MLflow and FUXA directly intersect with broader responsibilities around accessibility, resident services, and continuity of operations.
Protecting Accessible Digital Services
As more services—permit applications, benefits portals, student information systems, dashboards—are delivered through web and mobile channels, AI and data platforms increasingly sit behind the scenes. A compromise in supporting infrastructure can:
- Interrupt accessible online forms and content used by people with disabilities
- Expose personal information, including data covered by FERPA, HIPAA, or state privacy laws
- Degrade performance of assistive-technology compatible websites and portals
Technical accessibility (WCAG compliance, keyboard navigation, screen-reader support) depends on a secure and stable foundation. Unmanaged vulnerabilities in open-source components can threaten that foundation.
Risks to Sensitive and Regulated Data
MLflow environments may store or reference:
- De-identified but re-identifiable datasets used for modeling
- Linked records from student information systems, health systems, or case-management tools
- Operational data from public safety, transportation, or human services
If an attacker uses SSRF to access cloud credentials, they may gain indirect access to these datasets through storage services or databases, even if the MLflow application itself does not directly expose them.
Operational Disruption
Compromised cloud environments can affect:
- Scheduling and routing systems for transportation or field operations
- Automation controlling building environments and energy management
- Analytics dashboards used by leadership to make time-sensitive decisions
Aligning remediation with continuity-of-operations planning ensures that patching, access changes, and segmentation do not unintentionally disrupt essential services.
Recommended Actions for Government and Education Teams
1. Inventory and Exposure Assessment
- Identify any deployments of MLflow, FUXA, or similar open-source AI and OT platforms across your environment.
- Determine whether any of these systems are exposed to the public internet or reachable from untrusted networks.
- Map which cloud accounts, VPCs/VNETs, and on-premise segments they can access.
2. Apply Vendor and Community Patches
- Review the latest security advisories, release notes, and community guidance for MLflow and FUXA.
- Upgrade to patched versions where available, following change-management processes.
- Document patch status as part of your system security plans and authority-to-operate (ATO) packages where applicable.
3. Harden Configuration and Network Access
- Restrict MLflow and FUXA consoles to trusted administrative networks and VPNs.
- Implement strong authentication (SSO, MFA) and role-based access controls.
- Use network segmentation to prevent these tools from directly reaching sensitive back-end services unless explicitly required.
- For cloud-hosted deployments, restrict outbound access and apply firewall rules around metadata endpoints where feasible.
4. Protect Cloud Credentials and Secrets
- Move hard-coded credentials out of code and configuration into managed secrets services.
- Review IAM roles used by MLflow and similar tools; follow least-privilege principles.
- Rotate credentials potentially exposed through SSRF or other web vulnerabilities.
5. Integrate Open-Source Tools into Governance
- Include open-source AI and OT tools in your software bill of materials (SBOM) efforts.
- Align these platforms with existing vulnerability management, logging, and incident response processes.
- Incorporate accessibility, privacy, and security requirements into procurement documents when acquiring support, hosting, or integration services involving these tools.
6. Monitor, Test, and Train
- Ensure security monitoring covers MLflow, FUXA, and adjacent infrastructure (web proxies, gateways, cloud logs).
- Perform periodic penetration testing and configuration reviews of AI/ML and OT-related systems.
- Provide targeted training to data science, facilities, and IT teams on secure use of open-source platforms.
Using Procurement and Modernization to Reduce Risk
Public-sector organizations can use upcoming procurements, modernization projects, and cloud migrations as opportunities to address risks from open-source components such as MLflow and FUXA:
- Embedding security and accessibility requirements into statements of work and RFPs
- Requiring partners to document how AI and OT tooling will be patched, monitored, and segmented
- Clarifying responsibilities for credential management, secrets storage, and compliance with agency policies
- Ensuring web-based consoles and dashboards meet both security baselines and usability standards for staff with disabilities
By treating ML lifecycle tools and SCADA/HMI platforms as governed enterprise systems—not just developer utilities—agencies can better protect resident data, internal operations, and the reliability of digital services.
Conclusion: Secure Foundations for Accessible, Reliable Services
The active exploitation of vulnerabilities in MLflow and FUXA illustrates how quickly weaknesses in supporting tools can be weaponized. For state and local governments, school districts, and community-serving organizations, AI and OT platforms must be managed as part of a comprehensive security and accessibility strategy.
Assessing exposure, applying patches, hardening cloud and network configurations, and integrating these tools into governance processes are critical steps. Doing so strengthens the foundation beneath accessible websites, digital case management, analytics, and facilities systems that residents and staff rely on every day.
If your organization is planning or modernizing AI, cloud, or web-based control environments and needs support aligning them with accessibility, security, and governance requirements, you can learn more about Izende’s digital-service capabilities for public and community-serving organizations at https://izendestudioweb.com/government.
M Barton Productions LLC d/b/a Izende Studio Web provides digital-service capabilities to public and community-serving organizations. This article is informational and does not claim a completed government engagement.