Search: SHA-256

A malicious file identified by the SHA-256 hash ef42e6fd238baa990731f2ab20d130c489c1689588c5842713f28b4e90724019 was observed twice on July 21, 2026, by OffSeq Mirage honeypot sensors. The file is associated with attacker activity involving the MITRE ATT&CK technique T1105 (Ingress Tool Transfer). The malicious payload could be a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in Great Britain. This indicator can be used to detect the presence of this specific malicious file in environments by matching the hash against files and threat intelligence feeds.

A malicious file identified by the SHA-256 hash 50cffb0f65d31b38f5b222955d92879a3e102d0a0d9a3625ed87fb7834fab210 was observed by OffSeq Mirage honeypot sensors on July 21, 2026. This file was seen twice in attacker activity involving the T1105 technique (Ingress Tool Transfer) and originated from attacker infrastructure in Great Britain. The file is associated with a malicious payload such as a dropper, web shell, miner, or post-exploitation tool. No specific software versions are affected, and no known exploits or threat actors are linked to this indicator. The observation serves as an indicator of compromise for detection and response purposes.

A malicious file identified by the SHA-256 hash 7eeb49a12710a14273958e8a5c0594987416ce88d46e57f5c28906d9ff892c1d was observed twice on July 20, 2026, by OffSeq Mirage honeypot sensors. The file is associated with attacker activity involving the MITRE ATT&CK technique T1105 (Ingress Tool Transfer). This hash fingerprints a specific malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in the United States. No known exploits or threat actors are currently linked to this indicator, and no affected software versions are specified.

A malicious file identified by the SHA-256 hash d8a8cea14b12aa75047979f929bdf10b9003884580398c3c13d2b4fb04209410 was observed by OffSeq Mirage honeypot sensors on July 20, 2026. This file was detected 10 times during attacker activity involving the T1105 technique (Ingress Tool Transfer). The malicious payload could be a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in Poland and Vietnam. This indicator can be used to detect the presence of this specific malicious file in environments and security tools.

In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Validate CHAP_R length before base64 decode chap_server_compute_hash() allocates client_digest as kzalloc(chap->digest_size) and then, for BASE64-encoded responses, passes chap_r directly to chap_base64_decode() without checking whether the input length could produce more than digest_size bytes of output. chap_base64_decode() writes to the destination unconditionally as long as there is input to consume. With MAX_RESPONSE_LENGTH set to 128 and the "0b" prefix stripped by extract_param(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digest_size=32) this overflows client_digest by 63 bytes; for MD5 (digest_size=16) the overflow is 79 bytes. The length check at line 344 fires after the write has already happened. The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIV_ROUND_UP(digest_size * 4, 3) before calling the decoder. Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chap_base64_decode() already returns early on '=', so the full original string is still passed to the decoder unchanged. The mutual CHAP path decodes CHAP_C into initiatorchg_binhex, which is kzalloc(CHAP_CHALLENGE_STR_LEN). extract_param() caps initiatorchg at CHAP_CHALLENGE_STR_LEN characters, so at most CHAP_CHALLENGE_STR_LEN-1 base64 characters reach the decoder. The maximum decoded size, DIV_ROUND_UP((CHAP_CHALLENGE_STR_LEN-1) * 3, 4), is less than CHAP_CHALLENGE_STR_LEN, so no overflow is possible there. A comment is added at the call site to document this.

A malicious file identified by the SHA-256 hash 31d4181843b1ed10a7e7cb3f108f6d6c50a7a4452ee52ddacabe8ca77260615e was observed by OffSeq Mirage honeypot sensors five times between July 19 and July 30, 2026. The file is associated with attacker activity involving the MITRE ATT&CK technique T1105 (Ingress Tool Transfer). The malicious payload could be a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in Germany. This indicator can be used to detect the presence of this specific malicious payload in environments by matching the hash against files in endpoint detection and response (EDR), antivirus (AV), and threat intelligence feeds.

A malicious file identified by the SHA-256 hash a531f3e6224862abd00091c4955d535ace2bb886df53bdcd59c3a32b44c93629 was observed by OffSeq Mirage honeypot sensors during attacker activity between July 19 and July 22, 2026. The file is associated with the MITRE ATT&CK technique T1105 (Ingress Tool Transfer) and may represent a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in Germany. This indicator can be used to detect the presence of this malicious payload in environments by matching against endpoint detection and response (EDR), antivirus (AV), and threat intelligence feeds.

A malicious file identified by the SHA-256 hash e981d296a7034bc03a3a84185b5ac07d26afc01004f55cafadfaad1c42d70f40 was observed by OffSeq Mirage honeypot sensors during attacker activity between July 19 and July 22, 2026. The activity involved the MITRE ATT&CK technique T1105 (Ingress Tool Transfer), indicating the file was used to stage or deliver a malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in Germany. This hash serves as an indicator of compromise (IOC) to detect this specific malicious payload in environments and security tools.

A malicious file identified by the SHA-256 hash a485511f190cca50a45098bddd4f45f7bdeb8467f12cf726d1659fa3326aa5be was observed by OffSeq Mirage honeypot sensors during attacker activity from July 19 to July 22, 2026. The file is associated with the MITRE ATT&CK technique T1105 (Ingress Tool Transfer) and was seen originating from attacker infrastructure in Germany. This hash fingerprints a specific malicious payload which could be a dropper, web shell, miner, or post-exploitation tool. Organizations are advised to check for this file hash in their environments and security telemetry to detect potential compromise.

A malicious file identified by the SHA-256 hash 8ec920a35a7c6dd60e4aeb3b1ed09cd344f4c5191d4314a05ce72bf757377c86 was observed in attacker activity between July 19 and July 22, 2026. The file is associated with the MITRE ATT&CK technique T1105 (Ingress Tool Transfer) and was seen originating from attacker infrastructure in Germany. This hash fingerprints a specific malicious payload that could be a dropper, web shell, miner, or post-exploitation tool. The file was detected twice by OffSeq Mirage honeypot sensors. No known exploits in the wild or affected software versions are reported.

A malicious file identified by the SHA-256 hash f3a8ffee82d63d285245f66f82f7add5a056a20f4b339e8cdd218ffd3ac6314d was observed by OffSeq Mirage honeypot sensors during attacker activity from July 19 to July 22, 2026. The file is associated with the MITRE ATT&CK technique T1105 (Ingress Tool Transfer) and was seen originating from attacker infrastructure in Germany. This hash fingerprints a specific malicious payload that could be a dropper, web shell, miner, or post-exploitation tool. There is no information about known exploits in the wild or affected software versions. Organizations are advised to match this hash against files in their environments and security tools to detect potential compromise.

A malicious file identified by the SHA-256 hash ee793426a461ac5fc085115c485384c4bddff626b12c87b7663203fbd524529b was observed by OffSeq Mirage honeypot sensors on July 19, 2026. This file was detected 11 times during attacker activity and is associated with the MITRE ATT&CK technique T1105 (Ingress Tool Transfer). The file likely represents a malicious payload such as a dropper, web shell, miner, or post-exploitation tool used during attacks originating from infrastructure in the Philippines. No specific software versions are affected, and no known exploits in the wild have been reported for this indicator.

A malicious file identified by the SHA-256 hash d6bb2dc0431405c4158cc15ed0171fd3a53986bc79149ada27dec7b1edcf5b14 was observed by OffSeq Mirage honeypot sensors on July 19, 2026. The file was seen six times in attacker activity involving the T1105 technique (Ingress Tool Transfer). This hash corresponds to a specific malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was located in Brazil. There is no information about known exploits in the wild or affected software versions.

A malicious file identified by the SHA-256 hash f74a8b06db4f8f48f4a19ea5c01bade2a0dfb9290c4ed04a3f1a3eaa298a843d was observed by OffSeq Mirage honeypot sensors during attacker activity between July 18 and July 19, 2026. The file is associated with the MITRE ATT&CK technique T1105 (Ingress Tool Transfer) and is linked to attacker infrastructure located in the Netherlands and the United States. This hash fingerprints a specific malicious payload that could be a dropper, web shell, miner, or post-exploitation tool. Organizations are advised to check their environments and security tools for this hash to detect potential compromise. No known exploits in the wild have been reported for this file. No affected software versions or patches are applicable as this is an indicator of compromise rather than a vulnerability.

A malicious file identified by the SHA-256 hash 63952f1d3a85ae646317fd592027e258e1dbbba8c7bd4822e2551b9f0a4f8315 was observed 64 times in attacker activity between July 18 and July 21, 2026. The file is associated with the MITRE ATT&CK technique T1105 (Ingress Tool Transfer), indicating it was used to stage or deliver a malicious payload such as a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was observed in multiple countries including Brazil, China, Indonesia, India, Iran, Italy, Pakistan, and Thailand. This indicator should be matched against files in environments and security tools to detect potential compromise.

A malicious file identified by the SHA-256 hash 154d5729d26ae38ff37e7d1463a019d259da7c0f9a37e4482333e1e686ebe39e was observed by OffSeq Mirage honeypot sensors on July 18, 2026. This file was detected three times during attacker activity involving the T1105 technique (Ingress Tool Transfer). The malicious payload could be a dropper, web shell, miner, or post-exploitation tool. The file was associated with attacker infrastructure located in Brazil and Iran. Organizations are advised to match this hash against files in their environments and security telemetry to detect potential compromise.

A malicious file identified by the SHA-256 hash abcaddee7bcb727818464f54737eb2547a406215fcff914d5c270204030aacd7 was observed by OffSeq Mirage honeypot sensors on July 18, 2026. The file was seen four times during attacker activity involving the T1105 technique (Ingress Tool Transfer). The malicious payload could be a dropper, web shell, miner, or post-exploitation tool. The attacker infrastructure was observed in Brazil and China. This indicator can be used to detect or block the associated malicious file in security environments.

### Summary `joserfc.jwt.decode` accepts attacker-forged HMAC-signed tokens when the caller-supplied verification key is the empty string or `None`. `HMACAlgorithm.sign` and `HMACAlgorithm.verify` in [`src/joserfc/_rfc7518/jws_algs.py:62-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L62-L70) feed whatever `OctKey.get_op_key(...)` produced into `hmac.new(...)`, and `OctKey.import_key` only emits a `SecurityWarning` when the raw key is shorter than 14 bytes without rejecting zero-length input. Any application whose JWT secret is sourced from an unset environment variable, an unset Redis / DB row, a key finder fallback that returns `""`, or a `Hash.new("")`-style default verifies attacker tokens forged with `HMAC(key=b"", signing_input)` because the attacker trivially reproduces the same digest with no secret knowledge. This is a cross-language sibling of jwt/ruby-jwt GHSA-c32j-vqhx-rx3x / CVE-2026-45363 (HS256/HS384/HS512 verify accepted an empty/nil HMAC key, filed 2026-05-13). ruby-jwt v3.2.0 added an `ensure_valid_key!` precondition that rejects empty keys at both sign and verify entry; joserfc has no equivalent. (The same primitive lives in the deprecated `authlib.jose` module by the same maintainer; filing this advisory against joserfc alongside a separate `authlib` advisory because the codebases are independent shipping artifacts on PyPI.) ### Affected versions `joserfc` (PyPI) `<= 1.6.7` (latest published release reproduces). No patched release. ### Privilege required Unauthenticated. Any HTTP / RPC endpoint that calls `joserfc.jwt.decode` with a verification key sourced from configuration is reachable. The condition that makes the bug observable is operator-side: the configured secret resolves to `""` or `None`. Common patterns that produce this state in production: - `OctKey.import_key(os.environ.get("JWT_SECRET", ""))` - A key finder callable that returns `""` / `None` for an unknown `kid` - Default values like `os.getenv("SECRET") or ""`, `cfg.get("secret", "")` - Database / Redis row lookup that returns `""` for a missing row ### Vulnerable code [`src/joserfc/_rfc7518/jws_algs.py:43-70`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/jws_algs.py#L43-L70): ```python class HMACAlgorithm(JWSAlgModel): SHA256 = hashlib.sha256 SHA384 = hashlib.sha384 SHA512 = hashlib.sha512 def __init__(self, sha_type, recommended=False): self.name = f"HS{sha_type}" self.description = f"HMAC using SHA-{sha_type}" self.recommended = recommended self.hash_alg = getattr(self, f"SHA{sha_type}") self.algorithm_security = sha_type def sign(self, msg: bytes, key: OctKey) -> bytes: op_key = key.get_op_key("sign") return hmac.new(op_key, msg, self.hash_alg).digest() def verify(self, msg: bytes, sig: bytes, key: OctKey) -> bool: op_key = key.get_op_key("verify") v_sig = hmac.new(op_key, msg, self.hash_alg).digest() return hmac.compare_digest(sig, v_sig) ``` [`src/joserfc/_rfc7518/oct_key.py:52-63`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/src/joserfc/_rfc7518/oct_key.py#L52-L63): ```python @classmethod def import_key(cls, value, parameters=None, password=None) -> "OctKey": key: OctKey = super(OctKey, cls).import_key(value, parameters, password) if len(key.raw_value) < 14: # https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final warnings.warn("Key size should be >= 112 bits", SecurityWarning) return key ``` The `< 14` check only warns; `len(key.raw_value) == 0` falls through and is returned to the caller. `HMACAlgorithm.verify` then calls `hmac.compare_digest(sig, hmac.new(b"", signing_input, sha256).digest())`, and Python's `hmac.new(b"", ...)` accepts the empty key. Cross-language sibling of ruby-jwt's fix in [`lib/jwt/jwa/hmac.rb`](https://github.com/authlib/joserfc/blob/1ddca8f3c73ff47e3bc3ac06cb0c08a9535677ec/lib/jwt/jwa/hmac.rb): ```ruby def ensure_valid_key!(key) raise_verify_error!('HMAC key expected to be a String') unless key.is_a?(String) raise_verify_error!('HMAC key cannot be empty') if key.empty? end ``` invoked from both `sign(signing_key:)` and `verify(verification_key:)`. PyJWT landed an equivalent guard in 2.13.0 (`HMACAlgorithm.prepare_key` raises `InvalidKeyError("HMAC key must not be empty.")` for `len(key_bytes) == 0`). firebase/php-jwt rejects empty material in `Key.__construct`. jjwt enforces a 256-bit minimum in `DefaultMacAlgorithm.validateKey`. joserfc has the strongest existing length-warning logic but stops at `< 14 bytes` warn rather than `== 0` reject. ### How an empty `JWT_SECRET` reaches `hmac.new` 1. The application calls `joserfc.jwt.decode(value, key, algorithms=["HS256"])` where `key = OctKey.import_key("")` (or `OctKey.import_key(b"")`, or any custom path t

A vulnerability in com.ongres.scram:scram-client versions prior to 3.3 allows a TLS man-in-the-middle attacker to silently downgrade SCRAM authentication from SCRAM-SHA-256-PLUS (with channel binding) to SCRAM-SHA-256 (without channel binding). This occurs when the server presents an X.509 certificate using modern signature algorithms that the client cannot parse properly, causing fallback to a less secure authentication method without error. This can bypass strict channel binding policies in affected deployments.

A malicious file identified by the SHA-256 hash 201b1a44204bb8e3ade6a1694512c86f6b1067b07e8008e3434ac80e78dd5c31 was observed by OffSeq Mirage honeypot sensors on July 17, 2026. The file was detected twice in attacker activity involving the T1105 technique (Ingress Tool Transfer). The malicious payload could be a dropper, web shell, miner, or post-exploitation tool. The file was seen originating from attacker infrastructure in Brazil and Iran. There is no known exploit in the wild or vendor patch information associated with this indicator. Organizations are advised to match this hash against their environments and security tools to detect potential compromise.