A real audit of a public codebase, not a mockup and not a client's report.
The application is forem/forem,
an open-source Rails application, as it was at commit ea1291b
on October 1, 2026. Every number below comes from that code, through the same checks and the same
report template a client's audit goes through.
Nothing is redacted, because nothing here is private: you can check any finding against the code at that commit.
The project's maintainers did not commission this and are not a client. I don't publish a client's report,
redacted or not, without their written permission.
The findings come from the published code alone. Where a setting is decided by the deployment, the report says
so and asks for it to be confirmed; in an engagement that confirmation happens with you. The three findings
shown in full below were checked against the code at that commit.
Part one · pages 1 to 5
For the person deciding
Counts, days and plain language. No gem names, advisory numbers or version numbers.
Page 2
Where you stand
No critical issues were found, but 11 high issues should be scheduled soon.
- 11
- high
- 34
- medium
- 3
- low
- 43
- developer-days to fix everything
What matters most
- A third-party component the application depends on has a published security flaw. high
- The framework version is in its final support phase and will stop receiving security fixes. medium
- Whether the application insists on an encrypted connection depends on a setting that could not be confirmed from the code. medium
If nothing is done
If nothing is done, expect the high-severity items to become urgent within the next 6 to 12 months, as support periods end and the distance to a supported setup grows.
Page 3
What we examined
24 conditions examined across 4 areas.
14 passed.
A passed condition is a place you do not need to spend money.
| Area |
Examined |
Passed |
Failed |
| Known vulnerabilities in Ruby dependencies |
1 |
0 |
1 |
| Security configuration |
15 |
12 |
3 |
| Rails and Ruby versions |
6 |
2 |
4 |
| Rails upgrade path |
2 |
0 |
2 |
Also reviewed as a whole:
known vulnerabilities in JavaScript dependencies, automated tests, continuous integration, deployment, monitoring and error tracking, dependency freshness, database schema, and code quality tooling.
Pages 4 and 5
The work, and the order to do it in
Each block is a piece of work that can be approved or declined on its own. Together they come to
43 developer-days.
1. Immediate security remediation
8 developer-days
Closes the known, publicly documented ways into the application before anything else is built on top of it.
Closes 11 findings, the most serious rated high
2. Framework currency
15 developer-days
Returns the application to versions that still receive security fixes, which every later improvement depends on.
Closes 6 findings, the most serious rated medium
3. Engineering foundation
20 developer-days
Puts in place the automated checks that stop these problems from coming back once they are fixed.
Closes 31 findings, the most serious rated medium
None of these blocks depends on another, so they can be done in any order or in parallel. This is the order I recommend.
Part two · the findings register
For the engineer who checks it
Every finding has its evidence, where it is in the code, why it is rated as it is, how to fix it and how long that takes.
3 findings of 48 shown here; the rest are in the PDF.
high
Known vulnerability in faraday
- Evidence
- Gemfile.lock pins faraday 2.14.2, which is affected by CVE-2026-54297: Faraday - Uncontrolled recursion in NestedParamsEncoder allows stack exhaustion DoS via deeply nested query parameters.
- Where
-
Gemfile.lock: faraday (2.14.2)
- Impact
- The application runs faraday 2.14.2, which has a published vulnerability rated high (CVE-2026-54297). Flaws at this rating typically let an attacker read or change data, or take the application down, under conditions that are realistic for an internet-facing app. The details are public.
- Remediation
- Upgrade faraday to a patched release (~> 1.10.6, >= 2.14.3) with
bundle update faraday, run the test suite, and deploy. If the patched release is a major version ahead, read its changelog first. Advisory: https://www.cve.org/CVERecord/SearchResults?query=CVE-2026-54297
- Estimate
- 4 hours
medium
Rails 8.0.5 receives security fixes only
- Evidence
- Gemfile.lock pins rails 8.0.5. The 8.0 series is in security-only maintenance.
- Impact
- The application runs Rails 8.0.5. The 8.0 series still gets security patches but no bug fixes, and it is the next series to reach end of life. Nothing is exposed today.
- Remediation
- Schedule the upgrade to the next Rails series now, while it is one version away (the current release is 8.1.4). Clear the deprecation warnings on the current version first; they are the upgrade's to-do list.
- Estimate
- Counted in the upgrade steps
medium
HTTPS enforcement could not be confirmed from the code
- Where
-
config/environments/production.rb
- Impact
- The code does not itself require an encrypted connection; that is left to the deployment. If it is not enforced there either, anyone positioned on the network between a user and the server can read session cookies and submitted form data, including passwords.
- Why medium
config.force_ssl is set from ENV["FORCE_SSL_IN_RAILS"] == "true", not to true, so whether HTTPS is enforced depends on how the application is deployed. Confirm it is on in production.
- Remediation
- Confirm how production is configured. If HTTPS is enforced there, record where; otherwise set
config.force_ssl = true in config/environments/production.rb, after confirming the load balancer forwards X-Forwarded-Proto, or every request will redirect in a loop.
- Estimate
- 1 hour
The PDF is the whole
document, printed through the template a client's report is printed through: the cover, the five pages above, and all
48 findings.
Get an audit of your Rails application.
$2,500, fixed. Five business days. One application.
Book a 20-minute call