Square Capital selects Confluence Revolution Risk API to power next-generation risk analytics. Oct 13, 2026 Independent Parisian asset manager integrates Confluence's enterprise risk engine directly into its proprietary technology stack to support expanding investment strategies and associated AMF regulatory requirements. Pittsburgh, PA, October 13, 2026 - Confluence Technologies, Inc. ("Confluence"), a global leader in regulatory, analytics, and investor communications solutions for the investment management industry, today announced that Square Capital, the independent international asset manager specialising in Quality Investing, has selected Confluence's Revolution risk API as the core risk analytics engine for its next-generation investment risk framework. This selection strengthens Square Capital's pricing and risk management capabilities as it expands into more sophisticated investment strategies. Structured products such as Phoenix autocalls, reverse convertibles and capital-protected notes require Square Capital to meet new obligations from the Autorité des Marchés Financiers (AMF), the French regulator. Square Capital wanted to integrate the expanded risk capabilities needed into its existing in-house risk platform. Confluence Revolution risk API delivers institutional-grade risk intelligence through a modern, cloud-native architecture. It provides real-time access to advanced quantitative analytics, including Value at Risk, Expected Shortfall, stress testing across more than 2,900 scenarios, liquidity risk, credit analytics and hybrid risk decomposition. It also includes a pricing library of more than 360 functions spanning traditional assets, complex derivatives and structured products. Unlike traditional standalone risk platforms, Revolution risk API is designed to be embedded directly into a firm's proprietary workflows and applications so Square Capital gains access to enterprise-class analytics without replacing its existing systems. The solution integrates natively into Square Capital's existing risk environment, with minimal configuration and validation upon implementation. Confluence Technologies, Inc. were looking for a solution that combined analytical depth, flexibility and scalability that could integrate directly into its existing environment. Revolution risk API stood out for its ability to embed directly into its existing platform while providing the structured product coverage and pricing flexibility Confluence Technologies, Inc. need to support its expanding investment universe and satisfy its AMF requirements. Mathieu Pillet, Head of Risk & ESG at Square Capital As investment strategies grow in complexity and regulatory scrutiny intensifies, integrating enterprise-grade quantitative tools will be a competitive and compliance imperative, and firms will need to consider how to achieve this in the context of their existing technology stack. There is a growing demand for cloud-native risk analytics that are available via API to allow that flexibility. Square Capital's decision reflects a broader shift Confluence Technologies, Inc. is seeing across the industry: investment firms want sophisticated and comprehensive risk intelligence embedded in their operating model, not sitting alongside it. Revolution risk API is purpose-built for this use case. Confluence Technologies, Inc. is delighted to support Square Capital as it strengthens its risk capabilities and broadens its investment universe. Mark Evans, Chief Executive Officer at Confluence Technologies About Square Capital. Square Capital is an independent international asset manager founded in 2007 by two former Goldman Sachs Asset Management Executive Directors. The firm specialises in Quality Investing and manages approximately €1.6 billion on behalf of institutional and private investors. Square Capital operates from offices in Paris, London, Monaco and New York. For more information, visit squarecapitalgroup.com About confluence(r) Technologies. Confluence is a leading provider of specialist regulatory, analytics, and investor communication solutions for asset managers, asset servicers, investment consultants, and asset owners. Across performance, risk and peer analytics, regulatory filings and compliance monitoring, and shareholder reporting and document production, firms depend on Confluence for output they trust. Confluence Technologies, Inc. deliver this through deep domain expertise and purpose-built products developed over decades of research and engineering. Confluence solutions are powered by Confluence POINT, AI-enabled automation that runs within and alongside Confluence's trusted solutions. POINT optimizes inefficient workflows, delivering a meaningful impact on outcomes without requiring significant operational change. Headquartered in Pittsburgh, PA, with 750+ employees in 15 offices across the United Kingdom, Europe, North America, South Africa, and Australia, Confluence services over 1,000 clients in more than 40 countries. For more information, visit www.confluence.com. Confluence media contact: Jon Schubin

Atlassian CVE-2026-21589: A file-read bug meets a config file that holds a password. A critical Atlassian Data Center flaw lets anyone read named files in the web root, and exploitation attempts began within hours of a public proof of concept. The risk depends on what your web root contains. On its own, a bug that reads files you can name sounds modest. It stops being modest when one of the files is a configuration file holding a password. Atlassian disclosed CVE-2026-21589 on 5 October: a critical arbitrary file access flaw, rated 9.3, in eight Data Center and Server products including Jira, Confluence, Bitbucket, Bamboo and Crowd. A public proof of concept followed within a day, and honeypot operators say attempts to exploit it started within hours. Patching is the first job. The second is checking what an unauthenticated reader could have fetched from your servers, and what you would then have to rotate. What is confirmed. Atlassian describes an unauthenticated attacker being able to access specific files within an application's web root directory. It stresses the limits: the attacker must know the exact file name and path, and the flaw does not let them list directories. The affected products are Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible and Fisheye in their Data Center or Server form, and all versions before the fixed releases are affected regardless of configuration. Atlassian says its cloud products are already patched and need no action. Fixed versions reported from the advisory include Bitbucket 9.4.26, 10.2.8 and 10.5.1; Confluence 9.2.26 and 10.2.19; Jira Software 9.12.40, 10.3.26 and 11.3.12; Jira Service Management 5.12.40, 10.3.26 and 11.3.12; Bamboo 10.2.24 and 12.1.12; Crowd 6.3.7, 7.0.3, 7.1.7 and 7.2.4; and Crucible and Fisheye 4.9.15. Use Atlassian's bulletin for your exact product line. Atlassian also advises taking instances off the internet where possible, and says logins on public-facing instances do not remove the risk. It has published temporary mitigations, and says it cannot tell customers whether their own instances were accessed. watchTowr traced the bug to a web-resource library shared across the products, in routing code that turns a double-colon sequence into a path separator. Rapid7's testing found the read stays inside the application: it could not traverse outside the Tomcat context but could read files throughout the application web root. Why one file matters: the Crowd configuration. The write-ups describe a concrete chain. Atlassian's documentation places Crowd client settings in WEB-INF/classes/crowd.properties, which stores the application name and its password. That path is inside the web root. Rapid7 and BleepingComputer describe how, on a Jira instance integrated with Crowd, reading that file exposes the application credentials, and with network access to Crowd they could use them to create a user and add it to a Jira administrators group. The path to Crowd is the hard part. Crowd's IP allow-listing blocks the direct route, and reaching it from outside may need a pivot through another machine. That is a real limit, not a guarantee: any other file in the web root that holds a secret is a candidate. What counts is what your instances keep there, and you should check rather than assume. What is not established. * Confirmed compromises. BleepingComputer cites Previdian's honeypots seeing exploitation attempts within about two hours of watchTowr's public technical write-up, and watchTowr reports exploitation in the wild as of 6 October. Atlassian's advisory said its investigation found no evidence of exploitation, and the flaw was not on CISA's known-exploited list in the reporting Secretus reviewed. Attempts against honeypots are not proof that any customer was breached. * Which files were read. watchTowr says it does not know which files observed attackers targeted, or who they were. * Who found it. The reporter has not been named. * The credential chain beyond Crowd. The Crowd-to-Jira-admin route is a published demonstration. Secretus has no evidence it has been used against a real organisation. Public exploit scripts and a detection template for the vulnerability scanner Nuclei exist, and watchTowr has released a free scanner. Treat the window as open. A response order. * Find every Atlassian Data Center or Server instance, including old ones and ones managed by another team, and note the product, version and whether it is reachable from the internet. * Restrict exposure now. Take instances off the public internet where you can, put them behind a VPN or allow-list, and apply Atlassian's temporary rule while the upgrade is scheduled. Restrict Crowd to the hosts that need it. * Upgrade to a fixed release. Atlassian and Rapid7 both call for immediate patching, outside the normal window. * Search the logs. watchTowr suggests looking for a double dot next to a slash, backslash or double colon after decoding the URL up to twice. Keep the logs before any rotation or rebuild. * Inventory secrets in the web root. Look for properties files, configuration files, keys and anything else under the application directory that holds a password or token, starting with crowd.properties. Move secrets out of the web root where the product allows it. * Rotate on suspicion. If your logs show matching requests, or you cannot rule them out for an internet-exposed instance, rotate the Crowd application password and any credential found in files you identified. Then review Jira, Confluence and Bitbucket administrators for accounts nobody can account for. * Check what these systems connect to. Bitbucket and Bamboo typically hold repository tokens, deployment keys and CI variables. If an instance was compromised, those are the next secrets to rotate, so find them before an incident, not during. The handover step. Rotating a Crowd application password or a deployment key means giving the new value to whoever configures it, often a platform team or an external administrator. Under pressure these end up in the chat channel where the incident is being run, which is exactly the kind of place an attacker with a foothold in your tooling can read. Send each value once, to the one person who needs it, over a channel that does not keep it. Where Secretus fits, and where it does not. Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret, such as a break-glass administrator password. It is not an Atlassian security tool. It cannot patch Jira or Crowd, search your logs, move a secret out of a web root, or tell you whether CVE-2026-21589 was used against you. Do those with Atlassian's guidance and your own process, and use a one-time link for the step where one person gives another a value.