Security
Headlines
HeadlinesLatestCVEs

Tag

#perl

Yealink IP Phones and RPS (Redirect and Provisioning Service)

View CSAF 1. EXECUTIVE SUMMARY CVSS v4 5.3 ATTENTION: Exploitable remotely/Low attack complexity Vendor: Yealink Equipment: IP Phones Vulnerability: Improper Restriction of Excessive Authentication Attempts, Allocation of Resources Without Limits or Throttling, Incorrect Authorization, Improper Certificate Validation 2. RISK EVALUATION Successful exploitation of these vulnerabilities could result in an information disclosure. 3. TECHNICAL DETAILS 3.1 AFFECTED PRODUCTS The following versions of Yealink IP products are affected: SIP-T19P_E2: Versions prior to 53.84.0.121 SIP-T21P_E2: Versions prior to 52.84.0.121 SIP-T23G: Versions prior to 44.84.0.121 SIP-T40G: Versions prior to 76.84.0.121 SIP-T40P: Versions prior to 54.84.0.121 SIP-T27G: Versions prior to 69.84.0.121 SIP-T41S: Versions prior to 66.84.0.121 SIP-T42S: Versions prior to 66.84.0.121 SIP-T46S: Versions prior to 66.84.0.121 SIP- T48S: Versions prior to 66.84.0.121 SIP-CP920: Versions prior to 78.84.0.121 SIP-T53: Versions p...

us-cert
#vulnerability#web#git#perl#auth
GHSA-52f5-9888-hmc6: tmp allows arbitrary temporary file / directory write via symbolic link `dir` parameter

### Summary `tmp@0.2.3` is vulnerable to an Arbitrary temporary file / directory write via symbolic link `dir` parameter. ### Details According to the documentation there are some conditions that must be held: ``` // https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L41-L50 Other breaking changes, i.e. - template must be relative to tmpdir - name must be relative to tmpdir - dir option must be relative to tmpdir //<-- this assumption can be bypassed using symlinks are still in place. In order to override the system's tmpdir, you will have to use the newly introduced tmpdir option. // https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L375 * `dir`: the optional temporary directory that must be relative to the system's default temporary directory. absolute paths are fine as long as they point to a location under the system's default temporary directory. Any directories along the so specified path must exist, otherwise a ENOENT error will be...

The Role of Security Policies in Shaping Organisational Culture and Risk Awareness

Organisational culture, as we know it, isn’t built overnight. It takes shape over time through decisions, habits and…

Bitdefender Warns Users to Update Dahua Cameras Over Critical Flaws

Security researchers at Bitdefender have found two critical vulnerabilities (CVE-2025-31700, CVE-2025-31701) in popular Dahua security cameras, including the Hero C1 model.

GHSA-2rjv-cv85-xhgm: OpenSearch unauthorized data access on fields protected by field level security if field is a member of an object

### Impact OpenSearch versions 2.19.2 and earlier improperly apply Field Level Security (FLS) rules on fields which are not at the top level of the source document tree (i.e., which are members of a JSON object). If an FLS exclusion rule (like `~object`) is applied to an object valued attribute in a source document, the object is properly removed from the `_source` document in search and get results. However, any member attribute of that object remains available to search queries. This allows to reconstruct the original field contents using range queries. ### Patches The issue has been resolved in OpenSearch 3.0.0 and OpenSearch 2.19.3. ### Workarounds If FLS exclusion rules are used for object valued attributes (like `~object`), add an additional exclusion rule for the members of the object (like `~object.*`).

GHSA-rrmm-wq7q-h4v5: OpenSearch unauthorized data access on fields protected by field masking for fields of type ip, geo_point, geo_shape, xy_point, xy_shape

### Impact OpenSearch versions 2.19.2 and earlier improperly apply field masking rules on fields of the types `ip`, `geo_point`, `geo_shape`, `xy_point`, `xy_shape`. While the content of these fields is properly redacted in the `_source` document returned by search operations, the original unredacted values remain available to search queries. This allows to reconstruct the original field contents using range queries. Additionally, the content of fields of type `geo_point`, `geo_shape`, `xy_point`, `xy_shape` is returned in an unredacted form if requested via the `fields` option of the search API. ### Patches The issue has been resolved in OpenSearch 3.0.0 and OpenSearch 2.19.3. ### Workarounds If you cannot upgrade immediately, you can avoid the problem by using field level security (FLS) protection on fields of the affected types instead of field masking.

IR Trends Q2 2025: Phishing attacks persist as actors leverage compromised valid accounts to enhance legitimacy

Phishing remained the top initial access method in Q2 2025, while ransomware incidents see the emergence of new Qilin tactics.

GHSA-7rh7-c77v-6434: OAuth2-Proxy has authentication bypass in oauth2-proxy skip_auth_routes due to Query Parameter inclusion

### Impact This vulnerability affects oauth2-proxy deployments using the `skip_auth_routes` configuration option with regex patterns. The vulnerability allows attackers to bypass authentication by crafting URLs with query parameters that satisfy the configured regex patterns, potentially gaining unauthorized access to protected resources. The issue stems from `skip_auth_routes` matching against the full request URI (path + query parameters) instead of just the path as documented. This discrepancy enables authentication bypass attacks where attackers append malicious query parameters to access protected endpoints. Example Attack: * Configuration: `skip_auth_routes = [ "^/foo/.*/bar$" ]` * Intended behavior: Allow `/foo/something/bar` * Actual vulnerability: Also allows `/foo/critical_endpoint?param=/bar` Deployments using `skip_auth_routes` with regex patterns containing wildcards or broad matching patterns are most at risk, especially when backend services ignore unknown query para...