An issue was discovered in Free5GC v4.0.0 and v4.0.1 allowing an attacker to cause a denial of service via crafted POST request to the Npcf_BDTPolicyControl API.
Fluent Bit in_forward input plugin does not properly enforce the security.users authentication mechanism under certain configuration conditions. This allows remote attackers with network access to the Fluent Bit instance exposing the forward input to send unauthenticated data. By bypassing authentication controls, attackers can inject forged log records, flood alerting systems, or manipulate routing decisions, compromising the authenticity and integrity of ingested logs.
The extract_name function in Fluent Bit in_docker input plugin copies container names into a fixed size stack buffer without validating length. An attacker who can create containers or control container names, can supply a long name that overflows the buffer, leading to process crash or arbitrary code execution.
Fluent Bit out_file plugin does not properly sanitize tag values when deriving output file names. When the File option is omitted, the plugin uses untrusted tag input to construct file paths. This allows attackers with network access to craft tags containing path traversal sequences that cause Fluent Bit to write files outside the intended output directory.
Fluent Bit in_http, in_splunk, and in_elasticsearch input plugins fail to sanitize tag_key inputs. An attacker with network access or the ability to write records into Splunk or Elasticsearch can supply tag_key values containing special characters such as newlines or ../ that are treated as valid tags. Because tags influence routing and some outputs derive filenames or contents from tags, this can allow newline injection, path traversal, forged record injection, or log misrouting, impacting data integrity and log routing.
Fluent Bit in_http, in_splunk, and in_elasticsearch input plugins contain a flaw in the tag_key validation logic that fails to enforce exact key-length matching. This allows crafted inputs where a tag prefix is incorrectly treated as a full match. A remote attacker with authenticated or exposed access to these input endpoints can exploit this behavior to manipulate tags and redirect records to unintended destinations. This compromises the authenticity of ingested logs and can allow injection of forged data, alert flooding and routing manipulation.
Apache Syncope can be configured to store the user password values in the internal database with AES encryption, though this is not the default option.
When AES is configured, the default key value, hard-coded in the source code, is always used. This allows a malicious attacker, once obtained access to the internal database content, to reconstruct the original cleartext password values.
This is not affecting encrypted plain attributes, whose values are also stored using AES encryption.
Users are recommended to upgrade to version 3.0.15 / 4.0.3, which fix this issue.
Integer signedness error in tls_verify_call_back() in src/coap_openssl.c in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a crafted TLS certificate that causes i2d_X509() to return -1 and be misused as a malloc() size parameter.
NULL pointer dereference in coap_dtls_generate_cookie() in src/coap_openssl.c in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a crafted DTLS handshake that triggers SSL_get_SSL_CTX() to return NULL.
NULL pointer dereference in coap_dtls_generate_cookie() in src/coap_openssl.c in OISM libcoap 4.3.5 allows remote attackers to cause a denial of service via a crafted DTLS handshake that triggers SSL_get_SSL_CTX() to return NULL.