Security
Headlines
HeadlinesLatestCVEs

Tag

#git

Microsoft Credits EncryptHub, Hacker Behind 618+ Breaches, for Disclosing Windows Flaws

A likely lone wolf actor behind the EncryptHub persona was acknowledged by Microsoft for discovering and reporting two security flaws in Windows last month, painting a picture of a "conflicted" individual straddling a legitimate career in cybersecurity and pursuing cybercrime. In a new extensive analysis published by Outpost24 KrakenLabs, the Swedish security company unmasked the up-and-coming

The Hacker News
#windows#microsoft#git#The Hacker News
Malicious Python Packages on PyPI Downloaded 39,000+ Times, Steal Sensitive Data

Cybersecurity researchers have uncovered malicious libraries in the Python Package Index (PyPI) repository that are designed to steal sensitive information. Two of the packages, bitcoinlibdbfix and bitcoinlib-dev, masquerade as fixes for recent issues detected in a legitimate Python module called bitcoinlib, according to ReversingLabs. A third package discovered by Socket, disgrasya, contained a

GHSA-4fcv-w3qc-ppgg: rust-openssl Use-After-Free in `Md::fetch` and `Cipher::fetch`

When a `Some(...)` value was passed to the `properties` argument of either of these functions, a use-after-free would result. In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to `CString::drop`'s behavior). The maintainers thank [quitbug](https://github.com/quitbug/) for reporting this vulnerability to us.

Cyber Forensic Expert in 2,000+ Cases Faces FBI Probe

A Minnesota cybersecurity and computer forensics expert whose testimony has featured in thousands of courtroom trials over the past 30 years is facing questions about his credentials and an inquiry from the Federal Bureau of Investigation (FBI). Legal experts say the inquiry could be grounds to reopen a number of adjudicated cases in which the expert's testimony may have been pivotal.

GHSA-2frx-2596-x5r6: gitoxide does not detect SHA-1 collision attacks

### Summary gitoxide uses SHA-1 hash implementations without any collision detection, leaving it vulnerable to hash collision attacks. ### Details gitoxide uses the `sha1_smol` or `sha1` crate, both of which implement standard SHA-1 without any mitigations for collision attacks. This means that two distinct Git objects with colliding SHA-1 hashes would break the Git object model and integrity checks when used with gitoxide. The SHA-1 function is considered cryptographically insecure. However, in the wake of the SHAttered attacks, this issue was mitigated in Git 2.13.0 in 2017 by using the [sha1collisiondetection](https://github.com/crmarcstevens/sha1collisiondetection) algorithm by default and producing an error when known SHA-1 collisions are detected. Git is in the process of migrating to using SHA-256 for object hashes, but this has not been rolled out widely yet and gitoxide does not support SHA-256 object hashes. ### PoC The following program demonstrates the problem, using the...

GHSA-33xw-247w-6hmc: BentoML Allows Remote Code Execution (RCE) via Insecure Deserialization

### Summary A Remote Code Execution (RCE) vulnerability caused by insecure deserialization has been identified in the latest version(v1.4.2) of BentoML. It allows any unauthenticated user to execute arbitrary code on the server. ### Details It exists an unsafe code segment in `serde.py`: ```Python def deserialize_value(self, payload: Payload) -> t.Any: if "buffer-lengths" not in payload.metadata: return pickle.loads(b"".join(payload.data)) ``` Through data flow analysis, it is confirmed that the `payload `content is sourced from an HTTP request, which can be fully manipulated by the attack. Due to the lack of validation in the code, maliciously crafted serialized data can execute harmful actions during deserialization. ### PoC Environment: - Server host: - IP: 10.98.36.123 - OS: Ubuntu - Attack host: - IP: 10.98.36.121 - OS: Ubuntu 1. Follow the instructions on the BentoML official README(https://github.com/bentoml/BentoML) to set up the environment. 1.1 I...

Top Crypto Wallets of 2025: Balancing Security and Convenience

Crypto software wallets are invincible in the micro range. If you own multiple crypto assets, you need safe and reliable wallets, too.

GHSA-wg47-6jq2-q2hh: MinIO performs incomplete signature validation for unsigned-trailer uploads

### Impact This is a high priority vulnerability and users must upgrade ASAP. The signature component of the authorization may be invalid, which would mean that as a client you can use any arbitrary secret to upload objects given the user already has prior WRITE permissions on the bucket, Prior knowledge of access-key, and bucket name this user might have access to - and an access-key with a WRITE permissions is necessary. However with relevant information in place, uploading random objects to buckets is trivial and easy via `curl` ### Patches Yes https://github.com/minio/minio/pull/21103 ### Workarounds Reject requests with `x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER` for now at LB layer, ask application users to use `STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER`

GHSA-wc53-4255-gw3f: The XWiki JIRA extension allows data leak through an XXE attack by using a fake JIRA server

### Impact If the JIRA macro is installed, any logged in XWiki user could edit his/her user profile wiki page and use that JIRA macro, specifying a fake JIRA URL that returns an XML specifying a DOCTYPE pointing to a local file on the XWiki server host and displaying that file's content in one of the returned JIRA fields (such as the summary or description for example). For example: ``` <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <rss version="0.92"> ... <item> <title>&xxe;</title> <link>https://jira.xwiki.org/browse/XE-307</link> <project id="10222" key="XE">{RETIRED} XWiki Enterprise</project> <description>&xxe;</description> <environment/> ... ``` ### Patches The vulnerability has been patched in the JIRA Extension v8.6.5. ### Workarounds No easy workaround except to upgrade (which is easy using the XWiki Extension Manager). ### References * https://github.com/xwiki-contrib/jira/commit/98a...

GHSA-xcj6-pq6g-qj4x: Vite allows server.fs.deny to be bypassed with .svg or relative paths

### Summary The contents of arbitrary files can be returned to the browser. ### Impact Only apps explicitly exposing the Vite dev server to the network (using --host or [server.host config option](https://vitejs.dev/config/server-options.html#server-host)) are affected.. ### Details #### `.svg` Requests ending with `.svg` are loaded at this line. https://github.com/vitejs/vite/blob/037f801075ec35bb6e52145d659f71a23813c48f/packages/vite/src/node/plugins/asset.ts#L285-L290 By adding `?.svg` with `?.wasm?init` or with `sec-fetch-dest: script` header, the restriction was able to bypass. This bypass is only possible if the file is smaller than [`build.assetsInlineLimit`](https://vite.dev/config/build-options.html#build-assetsinlinelimit) (default: 4kB) and when using Vite 6.0+. #### relative paths The check was applied before the id normalization. This allowed requests to bypass with relative paths (e.g. `../../`). ### PoC ```bash npm create vite@latest cd vite-project/ npm insta...