- The Rails team's weekly update fixes a join bug that silently returned values from the wrong records, and a log filter that missed encoded parameter names.
- Quiet failures cost more than loud ones, because nobody knows to look for them.
- Ask your team how it learns about framework fixes and how soon it can apply them.
The bugs that never raise an alarm
A system that crashes gets fixed quickly. A system that returns a plausible wrong answer can run for years. That is the idea worth taking from this week's Rails changelog.
The Rails project publishes a weekly summary of what changed in the framework. The latest, written by Claudio Baccigalupo on October 30, reports 33 contributors in one week. Most items are small. Several describe failures that gave no sign they had happened.
Wrong answers, delivered calmly
The clearest case is in database joins. A join combines data from related tables. According to the Rails post, a query could reach the same "through" association by two different parent routes. The second route then borrowed the join built for the first. The post says the outcome was "silently returning values from the wrong records." The fix covers the left_joins and eager_load methods.
The post lists four pull requests that week on preloading through associations. Preloading is how Rails fetches related records ahead of time. That is a lot of repair work in one corner of the code. Any widely used framework will have corner cases like this, and the useful question is how quickly they are found.
A second case involves MySQL. For queries using count with limit, offset or distinct, the post says all optimizer hints moved to the outer query. Table-level hints such as INDEX(posts idx) were "silently ignored." Hints are instructions to the database about how to run a query. The fix keeps them on the subquery.
A third case involves column types. The immutable_strings_by_default setting was meant for string columns. The post says it reached every column whose type was built on the string type. That swept in text columns and several PostgreSQL types: xml, citext, ltree, tsvector and macaddr. Each was treated as a plain string, so its real type was lost. The change limits the setting to string columns.
A log filter that missed a disguised name
Rails can keep sensitive request parameters, such as passwords, out of its logs. It does this by matching parameter names against a filter list. URLs can write letters as percent codes, and %70 stands for the letter p.
The change now makes a :password filter catch a parameter written as %70assword, in request and redirect logs. That implies the encoded form was not matched before. The post does not say whether anyone relied on it or exploited it. It does show how a protection can look complete and still have a gap.
Smaller changes with a common thread
Other items follow the same pattern of tightening behaviour that was loose. Action Cable is the part of Rails that handles live, two-way connections. The post says commands sent over one connection could overlap or finish in the wrong sequence. They are now handled one after another, in order.
One CSRF setting, :header_only, relies on a browser-supplied header called Sec-Fetch-Site and does not use a token at all. Even so, forms, button_to and csrf_meta_tags kept producing a token each time a page rendered. They now produce none, so a page's bytes no longer change between requests.
The exists? method and calculations such as count now drop default_order, which the post says avoids invalid SQL on PostgreSQL. Reading or writing integer arrays in PostgreSQL no longer allocates one string per element.
Why this matters beyond Rails
These items are one week of work, not a trend. They also come from the project's own summary, not an independent audit. Still, they show where trust in software is decided. A framework earns it through attention to results that look right and are not.
WebPulse's NIST NVD profile lists 122 CVEs for Rails in total and 9 in the last 12 months. The profile counts 3 Rails entries in CISA's Known Exploited Vulnerabilities catalogue. Those are security flaws with CVE IDs. The fixes above are ordinary bug fixes, and the post assigns none a CVE.
What to ask your team
Ask who reads release notes for the frameworks your products run on, and how often. Ask how long it takes to apply a framework update once it ships.
Ask whether your applications use through associations with joins, MySQL optimizer hints or the immutable_strings_by_default setting. Those are the areas this week's post touches.
Ask whether your tests check query results against known data, not just that a query runs. A loud failure announces itself. A silent one waits for a customer, an auditor or a bad quarter to be found.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Ruby on Rails.
