Where
-Infinity
0
Severity
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Advantech Spectre RT ERT351 Versions 5.1.3 and prior has insufficient login authentication parameters required for the web application may allow an attacker to gain full access using a brute-force password attack.

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

Advantech Spectre RT ERT351 Versions 5.1.3 and prior logins and passwords are transmitted in clear text form, which may allow an attacker to intercept the request.

First published (updated )

XSS

Risk 38
Severity
6.1
XSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

In Advantech Spectre RT Industrial Routers ERT351 5.1.3 and prior, the affected product does not neutralize special characters in the error response, allowing attackers to use a reflected XSS attack.

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

The busybox NTP implementation doesn't check the NTP mode of packets received on the server port and responds to any packet with the right size. This includes responses from another NTP server. An attacker can send a packet with a spoofed source address in order to create an infinite loop of responses between two busybox NTP servers. Adding more packets to the loop increases the traffic between the servers until one of them has a fully loaded CPU and/or network.

It seems this bug was actually inherited from openntpd, on which the busybox implementation was based on. In openntpd it was fixed in:

https://github.com/openntpd-portable/openntpd-openbsd/commit/28a2f904aafbf4c209fe6fa04ffb9308740fd78a

Busybox upstream patch:

https://git.busybox.net/busybox/commit/?id=150dc7a2b483b8338a3e185c478b4b23ee884e71

1 / 2
Source: Red Hat
First published (updated )
Severity
10
Buffer Overflow
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

It was found that doaproutch function in crypto/bio/bprint.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not verify that a certain memory allocation succeeds, which allows remote attackers to cause a denial of service (out-of-bounds write or memory consumption) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data. This issues is different than CVE-2016-0799.

Upstream patch:

https://git.openssl.org/?p=openssl.git;a=commit;h=578b956fe741bf8e84055547b1e83c28dd902c73

1 / 3
First published (updated )
Severity
10
Buffer Overflow
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

As per Upstream advisory:

The internal |fmtstr| function used in processing a "%s" format string in the BIOprintf functions could overflow while calculating the length of a string and cause an OOB read when printing very long strings.

Additionally the internal |doaproutch| function can attempt to write to an OOB memory location (at an offset from the NULL pointer) in the event of a memory allocation failure. In 1.0.2 and below this could be caused where the size of a buffer to be allocated is greater than INTMAX. E.g. this could be in processing a very long "%s" format string. Memory leaks can also occur.

These issues will only occur on certain platforms where sizeof(sizet) > sizeof(int). E.g. many 64 bit systems. The first issue may mask the second issue dependent on compiler behaviour. These problems could enable attacks where large amounts of untrusted data is passed to the BIOprintf functions. If applications use these functions in this way then they could be vulnerable. OpenSSL itself uses these functions when printing out human-readable dumps of ASN.1 data. Therefore applications that print this data could be vulnerable if the data is from untrusted sources. OpenSSL command line applications could also be vulnerable where they print out ASN.1 data, or if untrusted data is passed as command line arguments.

Libssl is not considered directly vulnerable. Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on February 23rd by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team.

1 / 3
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