CVE-2026-47242: Net::IMAP: Command Injection via ID command argument

Published Jun 9, 2026
·
Updated

Summary

Two Net::IMAP commands, #id and #enable, do not validate their arguments. Arguments to either command could be used by an attacker to inject arbitrary IMAP commands.

Please note that passing untrusted inputs to these commands is usually inappropriate and expected to be uncommon.

Details

When Net::IMAP#id is called with a hash argument, although the ID field value strings are correctly quoted (escaping quoted specials), they were not validated to prohibit CRLF sequences.

While Net::IMAP#enable does process its arguments for aliases, it does not validate them as valid atoms (or as a list of valid atoms). The #tos value is sent verbatim.

Impact

This is expected to impact very few users: use of untrusted user input for either command is expected to be very uncommon.

The documentation for #enable explicitly warns that using any arguments that are not in the explicitly supported list may result in undocumented behavior. Using arbitrary untrusted user input for #enable will always be inappropriate.

Although client ID field values will most commonly be static and hardcoded, dynamic input sources may be used. For example, client ID fields may be set by configuration or version numbers. Using untrusted user inputs for client ID fields is expected to be uncommon. But any untrusted inputs to client ID can trivially exploit this vulnerability.

Untrusted inputs to either command may include a CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system's attributes, e.g.: shared mail folders or the application's installed response handlers.

Mitigation

Update to a version of net-imap which validates #id and #enable arguments.

Untrusted inputs should never be used for #enable arguments.

If net-imap cannot be upgraded: do not use untrusted inputs for client ID field values or add validation that client ID field values must not contain any CR or LF bytes.

Other sources

Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to 0.6.5 and 0.5.15, when Net::IMAP#id is called with a hash argument, although the ID field value strings are correctly quoted (escaping quoted specials), they were not validated to prohibit CRLF sequences. While Net::IMAP#enable does process its arguments for aliases, it does not validate them as valid atoms (or as a list of valid atoms). The #tos value is sent verbatim. Arguments to either command could be used by an attacker to inject arbitrary IMAP commands. This vulnerability is fixed in 0.6.5 and 0.5.15.

— NVD

Net::IMAP: Command Injection via ID command argument

— Microsoft

Affected Software

8 affected componentsFixes available
rubygems/net-imap<=0.5.14
0.5.15
rubygems/net-imap>=0.6.0<=0.6.4
0.6.4.1
Microsoft azl3 ruby 3.3.5-10<3.3.13-11
3.3.13-11
debian/ruby3.1*
debian/ruby3.3<3.3.13-0+deb13u1
3.3.13-0+deb13u1
debian/ruby3.3*
debian/ruby3.1<=3.1.2-7+deb12u1
debian/ruby3.3<=3.3.8-2, <=3.3.8-2.2
3.3.13-0+deb13u1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade rubygems/net-imap to a version that resolves this vulnerability.

    Fixed in 0.5.15
  2. Upgrade

    Upgrade rubygems/net-imap to a version that resolves this vulnerability.

    Fixed in 0.6.4.1
  3. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 3.3.13-11
  4. Upgrade

    Upgrade debian/ruby3.3 to a version that resolves this vulnerability.

    Fixed in 3.3.13-0+deb13u1
  5. Upgrade

    Upgrade net-imap to a version that resolves this vulnerability.

    Fixed in 0.6.5
  6. Upgrade

    Upgrade net-imap to a version that resolves this vulnerability.

    Fixed in 0.5.15
  7. Configuration

    Ensure any values passed to Net::IMAP#id for client ID field values are not derived from untrusted input; specifically validate that client ID field values do not contain any CR (\r) or LF (\n) bytes.

    Net::IMAP ID field values validation = must not contain CR or LF bytes
  8. Configuration

    Do not pass untrusted user input as arguments to Net::IMAP#enable (only use arguments from the explicitly supported list).

    Net::IMAP #enable arguments validation = use only explicitly supported arguments (no untrusted user input)

Event History

Jun 9, 2026
Advisory Published
via GitHub·08:31 PM
Data Sourced
via GitHub·08:31 PM
DescriptionWeaknessAffected Software
Jun 22, 2026
CVE Published
via MITRE·08:19 PM
Data Sourced
via MITRE·08:19 PM
DescriptionWeakness
Data Sourced
via NVD·09:16 PM
DescriptionSeverityWeakness
Data Sourced
via OSV·09:16 PM
DescriptionSeverityAffected Software
Jun 27, 2026
Data Sourced
via Microsoft·08:09 AM
DescriptionSeverityWeaknessAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Frequently Asked Questions

1

What is the severity of CVE-2026-47242?

CVE-2026-47242 has a risk score of 37, indicating a moderate severity level due to possible command injection vulnerabilities.

2

How do I fix CVE-2026-47242?

To fix CVE-2026-47242, update the 'net-imap' gem to version 0.6.4.1 or later, which contains patches for these vulnerabilities.

3

What software is affected by CVE-2026-47242?

CVE-2026-47242 affects the Ruby gem 'net-imap', specifically the commands '#id' and '#enable'.

4

What types of attacks are associated with CVE-2026-47242?

CVE-2026-47242 is associated with command injection and CRLF injection attacks, which allow unauthorized IMAP command execution.

5

When was CVE-2026-47242 published?

CVE-2026-47242 was published on June 9, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203