A denial of service vulnerability present in ActiveRecord's PostgreSQL adapter <7.0.4.1 and <6.1.7.1. When a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.
A vulnerability in ActiveRecord <6.0.6.1, v6.1.7.1 and v7.0.4.1 related to the sanitization of comments. If malicious user input is passed to either the annotate query method, the optimizer_hints query method, or through the QueryLogs interface which automatically adds annotations, it may be sent to the database with insufficient sanitization and be able to inject SQL outside of the comment.
There is a possible vulnerability in ActiveRecord related to the sanitization of comments. Previously the implementation of escaping for comments was insufficient. If malicious user input is passed to either the annotate query method, the optimizer_hints query method, or through the QueryLogs interface which automatically adds annotations, it may be sent to the database with insufficient sanitization and be able to inject SQL outside of the comment. In most cases …
There is a potential denial of service vulnerability present in ActiveRecord’s PostgreSQL adapter. In ActiveRecord <7.0.4.1 and <6.1.7.1, when a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.
A possible escalation to RCE vulnerability exists when using YAML serialized columns in Active Record < 7.0.3.1, <6.1.6.1, <6.0.5.1 and <5.2.8.1 which could allow an attacker, that can manipulate data in the database (via means like SQL injection), the ability to escalate to an RCE.
When serialized columns that use YAML (the default) are deserialized, Rails uses YAML.unsafe_load to convert the YAML data in to Ruby objects. If an attacker can manipulate data in the database (via means like SQL injection), then it may be possible for the attacker to escalate to an RCE. There are no feasible workarounds for this issue, but other coders (such as JSON) are not impacted.
The PostgreSQL adapter in Active Record suffers from a regular expression denial of service (REDoS) vulnerability. Carefully crafted input can cause the input validation in the money type of the PostgreSQL adapter in Active Record to spend too much time in a regular expression, resulting in the potential for a DoS attack. This only impacts Rails applications that are using PostgreSQL along with money type columns that take user input.
The Active Record component in Ruby on Rails before 3.0.14, 3.1.x before 3.1.6, and 3.2.x before 3.2.6 does not properly implement the passing of request data to a where method in an ActiveRecord class, which allows remote attackers to conduct certain SQL injection attacks via nested query parameters that leverage improper handling of nested hashes, a related issue to CVE-2012-2661.
Ruby on Rails 3.0.x before 3.0.4 does not ensure that arguments to the limit function specify integer values, which makes it easier for remote attackers to conduct SQL injection attacks via a non-numeric argument.
Multiple SQL injection vulnerabilities in the quote_table_name method in the ActiveRecord adapters in activerecord/lib/active_record/connection_adapters/ in Ruby on Rails before 2.3.13, 3.0.x before 3.0.10, and 3.1.x before 3.1.0.rc5 allow remote attackers to execute arbitrary SQL commands via a crafted column name.
Multiple SQL injection vulnerabilities in Ruby on Rails before 2.1.1 allow remote attackers to execute arbitrary SQL commands via the (1) :limit and (2) :offset parameters, related to ActiveRecord, ActiveSupport, ActiveResource, ActionPack, and ActionMailer.
Ruby on Rails 2.3.9 and 3.0.0 does not properly handle nested attributes, which allows remote attackers to modify arbitrary records by changing the names of parameters for form inputs.
There is a vulnerability when Active Record is used in conjunction with JSON parameter parsing. This vulnerability is similar to CVE-2012-2660, CVE-2012-2694 and CVE-2013-0155.
When using the nested attributes feature in Active Record you can prevent the destruction of associated records by passing the allow_destroy: false option to the accepts_nested_attributes_for method. The allow_destroy flag prevents the :reject_if proc from being called because it assumes that the record will be destroyed anyway. However, this is not true if :allow_destroy is false so this leads to changes that would have been rejected being applied to the …
The create_with functionality in Active Record was implemented incorrectly and completely bypasses the strong parameter protection.
SQLi vulnerability in activerecord.
SQLi vulnerability in activerecord.
SQL injection vulnerability in activerecord/lib/active_record/connection_adapters/postgresql/cast.rb in Active Record in Ruby on Rails beta1, when PostgreSQL is used, allows remote attackers to execute "add data" SQL commands via vectors involving \ (backslash) characters that are not properly handled in operations on array columns.
When a hash is provided as the find value for a query, the keys of the hash may be converted to symbols. Carefully crafted requests can coerce params[:name] to return a hash, and the keys to that hash may be converted to symbols. All users running an affected release should either upgrade or use one of the work arounds immediately.
There is a vulnerability in the serialized attribute handling code in Ruby on Rails, applications which allow users to directly assign to the serialized fields in their models are at risk of Denial of Service or Remote Code Execution vulnerabilities.
The attr_protected method allows developers to specify a denylist of model attributes which users should not be allowed to assign to. By using a specially crafted request, attackers could circumvent this protection and alter values that were meant to be protected.
Due to the way Active Record interprets parameters in combination with the way that JSON parameters are parsed, it is possible for an attacker to issue unexpected database queries with "IS NULL" or empty where clauses. This issue does not let an attacker insert arbitrary values into an SQL query, however they can cause the query to check for NULL or eliminate a WHERE clause when most users wouldn't expect …
Due to the way dynamic finders in Active Record extract options from method parameters, a method parameter can mistakenly be used as a scope. Carefully crafted requests can use the scope to inject arbitrary SQL.
Due to the way Active Record handles nested query parameters, an attacker can use a specially crafted request to inject some forms of SQL into your application's SQL queries.
Ruby on Rails contains a flaw related to the way ActiveRecord handles parameters in conjunction with the way Rack parses query parameters. This issue may allow an attacker to inject arbitrary IS NULL clauses in to application SQL queries. This may also allow an attacker to have the SQL query check for NULL in arbitrary places.