Adapted from the Polish article, originally published on 02 May 2026 and updated on 02 October 2026. The English version was published on 02 October 2026.
A vulnerability notice lands in the engineering channel. Someone recognises the library, opens an upgrade ticket and assumes the issue is covered. Meanwhile, an older release is running in a customer’s environment and nobody knows who is responsible for updating it.
A published CVE tests whether the company can connect a dependency to deployed products, owners, remediation and customer commitments. Updating the library matters, but closing a ticket does not establish that every affected installation has been addressed.
The pac4j disclosures from April 2026 provide a useful historical example. The process lesson applies to SaaS teams, software development suppliers and companies maintaining software for customers across markets.
What you will learn
- What the two April pac4j advisories covered, with precise version boundaries.
- How to connect dependency inventory with exposure and ownership.
- What a response plan should say about patching, temporary controls and evidence.
- Why support terms and customer communication belong in the same process.
The historical case: two pac4j vulnerabilities
On 17 April 2026, CERT Polska disclosed two vulnerabilities in pac4j, a Java authentication and security library. Cross-site request forgery (CSRF) can cause a user’s browser to perform unwanted actions. LDAP injection can alter directory queries through crafted input.
The published CVE records give these ranges. The fixed versions are excluded from the affected ranges.
- CVE-2026-40458, CSRF: version 5.0 up to, but excluding, 5.7.10; version 6.0 up to, but excluding, 6.4.1. The fixes are 5.7.10 and 6.4.1. CERT Polska’s CVSS v4.0 assessment is 7.0, High.
- CVE-2026-40459, LDAP injection: version 4.0 up to, but excluding, 4.5.10; version 5.0 up to, but excluding, 5.7.10; version 6.0 up to, but excluding, 6.4.1. The fixes are 4.5.10, 5.7.10 and 6.4.1. The CVSS v4.0 assessment is 8.7, High.
The project’s security advisory confirms the fixes for pac4j-core and pac4j-ldap. These are the first fixes for those two issues, not a recommendation to freeze a deployment at an April version. Review the project’s current release notes and other relevant advisories when choosing an upgrade.
Neither identifier appeared in the CISA Known Exploited Vulnerabilities catalogue checked on 2 October 2026. Absence from that catalogue does not establish that exploitation has never occurred or justify leaving an exposed deployment unpatched.
Find the deployed dependency, not just its name in a repository
An inventory needs to connect a component and version to the products and environments where it is actually running. Include transitive dependencies, which another package brings into the application, and installations maintained outside the main SaaS environment.
For a relevant advisory, establish:
- which released builds contain the component and affected version;
- whether the affected module and functionality are used;
- which production, test and customer-managed environments run those builds;
- what permissions and network exposure matter to the attack;
- who can deploy a correction in each environment.
A software bill of materials can support this work. It needs a link to a released build and deployment records to answer the customer’s actual question: “Is our installation affected?”
Assign one person to coordinate the response. Engineering can investigate reachability, security can assess exposure and customer-facing teams can manage communication. The coordinator makes sure those activities produce one consistent status.
Triage should produce an action and a deadline
A severity score is an input to prioritisation. The deployment assessment still needs to consider the affected feature, possible impact, exposure and available mitigation. Record the reasoning if the team concludes that a particular installation is unaffected.
For each affected deployment, decide on an owner, target date and verification step. If an immediate patch is impractical, a temporary control might involve disabling the affected feature, restricting access or changing configuration. The technical team should test whether that control addresses the relevant attack path and record what remains exposed.
A temporary control needs an owner, evidence and an expiry or review date. Otherwise, an emergency exception can quietly become the permanent configuration.
Separate the patch being available, tested, deployed and verified. Those are different milestones, especially where customers control their own installations. A supplier may deliver an update while still needing to help a customer arrange the maintenance window.
The same discipline belongs in development contracts. Secure-by-design acceptance criteria can establish the initial security baseline; maintenance terms need to address what happens when that baseline requires an update.
A practical example: three installations, three responsibilities
Consider a hypothetical SaaS supplier that also supports two dedicated customer deployments. An affected dependency appears in all three builds. The SaaS team can deploy directly, one customer requires approval for a maintenance window, and another operates the application through a separate service provider.
A single “fixed” ticket would hide those differences. The response record should show the SaaS deployment verified, the first customer’s update awaiting approval with an assessed temporary control, and the second customer’s update delivered to its operator with installation instructions and a follow-up date.
Communication should identify the affected releases, relevant impact, available fix, any action required from the customer and the next update. Do not tell every customer there has been a breach merely because a CVE exists. If evidence suggests compromise, activate incident handling and assess notification duties under the applicable law and contracts separately.
Review the support contract before the next disclosure
A third-party vulnerability does not automatically establish a breach by the development supplier. The agreed scope, security commitments, maintenance obligations, knowledge and response matter. A lack of inventory or an unfulfilled response commitment can create a separate contractual problem.
Review whether the agreement answers these questions:
- Who monitors advisories and assesses relevant dependencies?
- When does a response clock start, and what does “response” require?
- Who supplies, tests, approves and deploys security updates?
- Which releases remain supported, and how are customers told about end of support?
- Who communicates status, and how are urgent contacts kept current?
- What evidence closes the issue, including customer-managed installations?
An availability SLA does not necessarily define security patch deadlines. Avoid using one percentage to stand in for several distinct commitments. Where the product falls within its scope, the Cyber Resilience Act’s security-update requirements also need a separate assessment of responsibilities and application dates.
Keep evidence that explains the decision
Retain the advisory, affected-build assessment, remediation plan, test results, deployment records and customer communications. Include the reasons for any deferred action and the person who approved it. This helps an engineer pick up the issue later and gives the company a coherent answer during an audit or dispute.
Open-source governance should connect component selection, licence review, security monitoring and support ownership. If those tasks sit in disconnected documents, the next disclosure will expose the gaps again.
For a review of the contractual side, IT contract and security support can address the allocation of work, deadlines and evidence alongside the technical response plan.