NewIntroducing ISO360 — our all-in-one ISO compliance platform
Cybersecurity · Compliance · Cyber Risk Advisory
NewIntroducing ISO360 — ISO compliance platform

Cybersecurity, Compliance & Risk Advisory for the Digital Age

R4IM helps organizations strengthen security, achieve ISO compliance, manage cyber risk, and respond faster to emerging vulnerabilities — through practical, business-focused advisory services.

Trusted across
ISO 27001ISO 22301ITSM / ISO 20000VA / PTCloud SecurityGRC AdvisoryUAE Experience
Free Cyber Advisory Intelligence

Know what's exploited today. Act before it hits you.

Stay informed about critical vulnerabilities, actively exploited CVEs, vendor advisories, and emerging cyber risks. R4IM continuously monitors trusted public sources and simplifies the actions organizations should take.

TrackedCVE-2026-55735
Vulnerability advisory

Improper Verification of Cryptographic Signature in ueberauth guardian allows an unauthenticated attacker to revoke a victim'…

Improper Verification of Cryptographic Signature in ueberauth guardian allows an unauthenticated attacker to revoke a victim's session with a forged token. Guardian.revoke/3 in lib/guardian.ex decodes the supplied token with peek/1, which performs no signature verification (it only base64-decodes the JWT header and payload). The resulting unverified claims are forwarded directly to the configured token module's revoke callback and the implementation's on_revoke callback, a state-mutating sink. The sibling operations refresh/2 and exchange/4 both call decode_and_verify first, so the signature is checked before anything acts on the claims; revoke/3 is the only state-mutating path that acts on claims without verifying the signature. An attacker who knows or guesses a victim's identifying claim values (jti, sub) can forge a JWT carrying those claims, sign it with an arbitrary key, and submit it to any endpoint that funnels a caller-supplied token into Guardian.revoke/3 (the standard logout / session-revocation pattern). When the token module mutates state keyed by the claims (whitelist deletion or blacklist insertion, for example a GuardianDb-style store), the victim's legitimate session is evicted. This is an unauthenticated session-revocation denial of service; the attacker never needs the signing secret. This issue affects guardian: from 1.0.0 before 2.4.1.

Updated Aug 1Remediation
TrackedCVE-2026-55734
Vulnerability advisory

Allocation of Resources Without Limits or Throttling vulnerability in ueberauth guardian (Guardian.Permissions module) allows…

Allocation of Resources Without Limits or Throttling vulnerability in ueberauth guardian (Guardian.Permissions module) allows a denial of service via BEAM atom-table exhaustion. This vulnerability is associated with program file lib/guardian/permissions.ex and program routines 'Elixir.Guardian.Permissions':encode_permissions!/1, 'Elixir.Guardian.Permissions':encode_permissions_into_claims!/2, 'Elixir.Guardian.Permissions':do_encode_permissions!/2. The Guardian.Permissions mixin installs a public encode_permissions!/1 function on every module that does use Guardian.Permissions. For each key of the supplied map, encode_permissions!/1 calls String.to_atom(to_string(k)) before any validation runs. The integer-value clause of do_encode_permissions!/2 then short-circuits straight to encoding without validating the key against the configured permission set, so a key with an integer value is interned as a fresh atom with no exception raised. Atoms are never garbage collected and the BEAM atom table is a fixed-size resource (default roughly 1,048,576 entries), so each unique attacker-chosen key permanently consumes one slot. An attacker who can influence a permission map that reaches encode_permissions!/1 (for example a permissions map read from a request body and passed into token issuance via encode_permissions_into_claims!/2) can mint an unbounded number of atoms and exhaust the atom table, crashing the entire BEAM node and every service running on it. The sibling decode_permissions/1 is not affected because it skips keys absent from the configured permission set. This issue affects guardian: from 2.0.0 before 2.4.1.

Updated Aug 1Remediation
TrackedCVE-2026-55733
Vulnerability advisory

Allocation of Resources Without Limits or Throttling in ueberauth guardian allows denial of service via unbounded atom creati…

Allocation of Resources Without Limits or Throttling in ueberauth guardian allows denial of service via unbounded atom creation from attacker-controlled binary input. Guardian.Permissions.AtomEncoding encodes permission scopes by passing arbitrary binaries to String.to_atom/1. When encode/3 in lib/guardian/permissions/atom_encoding.ex is called with a list, each binary entry is handled by the encode_value/3 binary clause, which calls String.to_atom(value) with no allow-list check. The perm_set argument (the application's small, finite set of legitimate permission names) is discarded, so any external string flows straight into atom creation. This encoder is selected with use Guardian.Permissions, encoding: Guardian.Permissions.AtomEncoding and reached through the imported encode/3 entry point. String.to_atom/1 creates a brand-new atom for every previously unseen binary, atoms are never garbage collected, and the BEAM atom table is fixed at roughly 1,048,576 entries by default. An application that funnels attacker-influenced permission scopes (from a request body, a JWT claim, or other external input) into encode/3 therefore mints one permanent atom per distinct value. A modest stream of varied, unauthenticated input permanently consumes the atom table and crashes the BEAM node with system_limit, taking down every application running on it. The default encoder is Guardian.Permissions.BitwiseEncoding, which is not affected. This issue affects guardian: from 2.0.0 before 2.4.1.

Updated Aug 1Remediation
TrackedCVE-2026-54894
Vulnerability advisory

Allocation of Resources Without Limits or Throttling in ueberauth guardian allows denial of service via unbounded atom creati…

Allocation of Resources Without Limits or Throttling in ueberauth guardian allows denial of service via unbounded atom creation from attacker-influenced binary input. Guardian.Plug.Keys derives connection and session namespace keys by passing arbitrary binaries to String.to_atom/1. base_key/1 in lib/guardian/plug/keys.ex converts any binary into the atom :"guardian_<input>", and the derived helpers claims_key/1, resource_key/1, and token_key/1 create a second atom on top of that. key_from_other/1 likewise converts a regex-captured binary through String.to_atom/1. The public specs advertise String.t() as a valid argument, so passing a string is documented usage, and higher-level entry points such as Guardian.Plug.current_token(conn, key: key) thread the caller-supplied key straight into these functions. String.to_atom/1 creates a brand-new atom for every previously unseen binary, atoms are never garbage collected, and the BEAM atom table is fixed at roughly 1,048,576 entries by default. An application that routes attacker-influenced data (a tenant identifier, header, or other request input) into a Guardian key therefore mints one permanent atom per distinct value. A modest stream of varied, unauthenticated input permanently consumes the atom table and crashes the BEAM node, taking down every application running on it. This issue affects guardian: from 0.1.0 before 2.4.1.

Updated Aug 1Remediation
TrackedCVE-2025-52936
Vulnerability advisory

Improper Link Resolution Before File Access ('Link Following') vulnerability in yrutschle sslh.This issue affects sslh: befor…

Improper Link Resolution Before File Access ('Link Following') vulnerability in yrutschle sslh.This issue affects sslh: before 2.2.2.

Updated Aug 1Remediation
MediumCVE-2024-10918
libmodbus · libmodbus

Stack-based Buffer Overflow vulnerability in libmodbus v3.1.10 allows to overflow the buffer allocated for the Modbus respons…

Stack-based Buffer Overflow vulnerability in libmodbus v3.1.10 allows to overflow the buffer allocated for the Modbus response if the function tries to reply to a Modbus request with an unexpected length.

Updated Aug 1Remediation
New Product

Meet ISO360

The all-in-one platform to plan, implement, and sustain ISO compliance.

Built by R4IM consultants for security, quality, and business continuity teams. ISO360 streamlines controls, evidence, risk, audits, and continual improvement across ISO 27001, ISO 22301, ISO 20000, and more — in one workspace.

  • Multi-standard control library
  • Evidence & document management
  • Risk register & treatment plans
  • Internal audits & CAPAs
  • Real-time compliance dashboards
  • Team collaboration & workflows
ISO360 · Live workspace
Online
Controls
128 / 156
Open risks
7
ISO 27001 readiness82%
ISO 22301 readiness68%
ISO 20000 readiness54%
Powered by R4IM · iso360.r4im.com
Why R4IM

Practical advisory.
Audit-ready outcomes.

We work shoulder-to-shoulder with your teams to close compliance gaps, reduce cyber risk, and build security programs your auditors and your board can both trust. Two decades of UAE and global experience across ISO, cybersecurity, cloud, and GRC.

20+
Years of advisory experience
150+
Engagements delivered
ISO
27001 · 22301 · 20000 practice
UAE
Local presence, global reach
Talk to a Consultant

Get a clear next step on your cyber & compliance roadmap.

A senior R4IM advisor will reply within one business day. UAE-based teams available for on-site engagements across the region.