Remove RichFaces from your business-critical Java applications

No. RichFaces reached end of life in June 2016 and has received no updates since, including no security patches. There is no supported release, no vendor behind it, and a shrinking pool of developers who still know it. Staying on it means any newly discovered vulnerability will never be fixed, and the framework keeps blocking the Java, application-server, and Jakarta EE upgrades around it. Removing RichFaces is the best path that closes the exposure and unblocks the rest of your modernization.

Yes; several, including multiple critical ones. The headline is CVE-2018-14667, a critical expression-language injection in RichFaces 3.x that allows remote code execution; it is listed in CISA's Known Exploited Vulnerabilities catalog and has been observed exploited in the wild. There are further critical, unauthenticated remote-code-execution flaws across both the 3.x and 4.x lines — CVE-2018-12533 and CVE-2018-12532, both rated CVSS 9.8 — plus the deserialization flaw CVE-2013-2165 and the code injection CVE-2015-0279. Because the project is dead, none of these will ever be officially patched upstream. The only durable fix is to remove RichFaces from your application.

It depends on your application and your team. Migrating to PrimeFaces keeps the JSF programming model and is often the safest, most cost-effective route when the app is fundamentally sound and business logic is tightly coupled to JSF. Moving to a modern JavaScript framework such as React, Angular, or Vue fits teams that want a modern frontend platform and have, or want, modern JS skills in-house. Large systems often land on a hybrid: high-value screens on PrimeFaces, selected modules rebuilt in JavaScript, on a modernized app server. We help you choose based on your actual code, team and goals.

Managed well, far less risky than staying put. We reduce risk with incremental migration, acceptance criteria defined with you per workflow, coexistence models that keep the app running, and the option to validate with a pilot before scaling. We recommend involving your QA function early and can build automated tests with Selenium or Playwright if you want that in scope. We have done this on systems far larger than most, so the failure modes are familiar and planned for.

Usually not. A full rewrite throws away decades of embedded business logic and carries enormous cost and risk. Our approach preserves business functionality while modernizing, and where a clean break genuinely makes sense we do it selectively, module by module, with coexistence rather than a big-bang gamble. Rewrites are the exception, chosen deliberately, not the default.

There is an unofficial community fork that has patched the known CVEs, and it can be a legitimate short-term way to close those specific holes. But it is a stopgap, not a strategy. It is a single-maintainer effort with no security team and no guarantee the next vulnerability gets fixed; adopting it is itself an upgrade with new dependencies and re-testing. It still requires JDK 8, old dependencies with their own security vulnerabilities, and old application servers. The fork can buy a little time on the CVEs; it cannot move your architecture forward.

AI coding agents are very capable, but complex applications require more than just a coding agent. We know because we've spent a lot of time cleaning up projects where the team attempted using a coding agent alone. We follow a structured process that includes AI-assisted analysis, OpenRewrite recipes for repeatable, deterministic changes, plus agent-driven changes and bug fixes. Architecture decisions, behavior preservation, complex JSF pages, and the judgment-heavy edge cases require senior engineers. Letting AI rewrite a mission-critical application unsupervised is how you get subtle, hard-to-find defects. Our model is machine-assisted and human-orchestrated: automation where it is safe, hand-written code where it is not, and senior engineers owning all of it.

You can, and sometimes using tools such as IBM Application Modernization Accelerator, Github Copilot App Modernization, and Amazon Q Developer:Transform is the right call; we use those tools ourselves when they fit. But for RichFaces specifically, three things separate our work from running a tool alone. The off-the-shelf tools do not ship recipes for RichFaces or PrimeFaces, which is the hardest, most framework-specific part; complex pages and edge cases still need deep JSF and PrimeFaces expertise; and a tool does not own the outcome. Running the tool is itself a project, and the project needs expert owners who decide scope, judge whether each fix is correct, and take responsibility for the migration being finished and shipped. That is the role we fill.

It depends on the size and complexity of the application, our level of involvement with the implementation and how much you want to improve along the way. The assessment produces sequenced phases and effort ranges so you can plan budget and timeline with real numbers.