Search: t**n*e**l s.a. c***t**c***a

WNC T-Mobile 5G Box IDU router contains a cross-site request forgery (CSRF) vulnerability in the portal.cgi component. The anti-CSRF mechanism fails to validate the csrf_token_value parameter, accepting any arbitrary value as valid. This allows a remote attacker to perform unauthorized actions on the device by tricking an authenticated user into visiting a malicious website.This issue has been fixed in firmware version 1.1.0.651412

WNC T-Mobile 5G Box IDU router is vulnerable to improper access control. The vulnerability exists in the wnc_maccheck.cgi endpoint, which is accessible without authentication. It allows a remote attacker to retrieve sensitive configuration data, including the administrator web password, WiFi passphrase, and technical device information.This issue has been fixed in firmware version 1.1.0.651412

WNC T-Mobile 5G Box IDU router is vulnerable to a command injection. The vulnerability exists in the ping functionality within the /cgi-bin/portal.cgi endpoint, specifically affecting the ping_ip, ping_size, and ping_times POST parameters. The root cause is the failure to verify and sanitize user-supplied input before incorporating it into a system command. This allows an authenticated attacker to execute arbitrary commands on the shell and gain root access to the system.This issue has been fixed in firmware version 1.1.0.651412

WNC T-Mobile 5G Box IDU router contains an authentication bypass vulnerability in the portal.cgi component. The session verification mechanism improperly validates the sessionid cookie by checking for the existence of a corresponding file in /tmp/login_user. An attacker can bypass authentication by using directory entries such as "." or ".." in the cookie, allowing unauthorized access to the administration panel.This issue has been fixed in firmware version 1.1.0.651412

A vulnerability in the Linux kernel arm64 architecture was resolved that involved reading the GMID_EL1 register even when Memory Tagging Extension (MTE) is disabled. This could cause an undefined instruction exception and kernel panic in pKVM environments when CPUs are offlined and brought back online. The fix gates the GMID_EL1 read based on CPU features and configuration to prevent this error.

A vulnerability in the Linux kernel's memory management subsystem (mm/page_alloc) was resolved to prevent unsafe use of spin_trylock() in non-maskable interrupt (NMI) context on uniprocessor (UP) systems. The issue could cause kernel crashes and may be exploitable by local attackers for privilege escalation when BPF programs operate in NMI on non-SMP builds. The vulnerability affects specific Linux kernel versions used in various Ubuntu releases.

A vulnerability in the Linux kernel's drm/xe driver component incorrectly handled the allocation of flat CCS storage as usable VRAM by rounding the memory offset upwards rather than downwards. This caused the VRAM allocator to include compression hardware memory as free memory, leading to memory corruption and potential faults in GPU operations such as compositor batch-buffer handling. The issue was resolved by changing the rounding method to round down to the page size, preventing overlap with reserved compression storage.

A vulnerability in the Linux kernel's network skbuff subsystem (CVE-2026-90049) involves improper handling of skb_zerocopy() error conditions. Specifically, skb_tx_error() is incorrectly called on the source skb during skb_orphan_frags() failure, which prematurely clears ownership flags and completes the zero-copy user argument. This can lead to use-after-free or data corruption when the skb is still in use by other parts of the networking stack, such as Open vSwitch or ESP processing. The issue has been resolved by leaving error reporting to the callers who already handle failure paths appropriately.

A vulnerability in the Linux kernel's qla2xxx SCSI driver could cause the adapter to hang during ISP reset or PCI error recovery. The issue arises from querying firmware state while the chip is down or EEH is busy, leading to unsynchronized mailbox commands and potential hangs. The flaw has been resolved by ensuring mailbox commands are issued only once, inside a mutex, and only when the chip is operational.

A vulnerability in the Linux kernel's dma-buf dma-heap subsystem allowed file descriptors (fd) to be published before a copy_to_user() operation succeeded, leading to fd and dma-buf reference leaks within the process. This was fixed by restructuring the allocation path to ensure the fd is only published after successful copy_to_user(), preventing leaks and race conditions.

CVE-2026-89912 is a high-severity vulnerability in the Linux kernel's KVM arm64 vgic-its component. It involves a NULL pointer dereference during ITT save operations triggered by a specific sequence of MAPC, MAPD, and MAPTI commands from a guest. This can cause the host to crash (oops) when migrating the guest using KVM_DEV_ARM_ITS_SAVE_TABLES. The issue is fixed by saving a zeroed entry instead of dereferencing the NULL collection pointer.

An unauthenticated attacker can inject arbitrary fake log lines into Apache ZooKeeper's operational log by sending a crafted add_auth("ensemble", ...) request containing newline characters (\n). When the ensemble name doesn't match, EnsembleAuthenticationProvider.handleAuthentication() logs the raw, unsanitized name via LOG.warn(). Because SLF4J's {} placeholder preserves embedded newlines, the attacker can forge complete log entries — with arbitrary timestamps, log levels, class names, and messages — that are visually indistinguishable from genuine ZooKeeper log output. This issue affects Apache ZooKeeper: from 3.9.0 through 3.9.5, from 3.8.0 through 3.8.6. Users are recommended to upgrade to version 3.8.7 or 3.9.6, which fixes the issue.

### Summary Once a user has TOTP enabled, the API still hands back the raw shared secret to anyone holding that account's access token. Reading it doesn't ask for the password, even though disabling TOTP does. So a stolen token, an XSS, or a browser left open is enough to copy the second factor into your own authenticator and keep generating valid codes indefinitely. ### Details `GET /api/v1/user/settings/totp` returns the full TOTP object, including the secret field and the otpauth:// provisioning URL. `GET /api/v1/user/settings/totp/qrcode` renders the same secret as a QR image. Neither requires re-authentication, the access token alone is enough. This is inconsistent with the rest of the flow: `POST /api/v1/user/settings/totp/disable` calls CheckUserPassword before it will turn TOTP off. So the destructive action is gated behind the password, but reading out the secret that backs the second factor isn't. There's also no reason for the secret to be readable at all once enrollment is finished, the client only needs it during setup. The fix is to stop returning secret/url/the QR code once enabled is true (only expose them during the enrollment window). Requiring the password on the read, like disable already does, would also be reasonable. ### PoC The attacker needs the victim's access token, from an XSS, a leaked/stolen token, or an unlocked session. TOTP must already be enabled on the account. 1. With the victim's bearer token, call: ``` GET /api/v1/user/settings/totp Authorization: Bearer <victim_token> ``` The response contains the shared secret and the otpauth:// URL: ``` {"secret": "<base32 secret>", "enabled": true, "url": "otpauth://totp/..."} ``` 2. Paste that secret (or scan `/api/v1/user/settings/totp/qrcode`) into any authenticator app. 3. It now produces the same 6-digit codes as the victim's device. Nothing is logged and the victim gets no notification. ### Impact This defeats the purpose of the second factor. 2FA is supposed to survive exactly this situation, a compromised password or a hijacked session, but a single read of the account's own settings hands over the shared secret with no step-up check and no trace. Combined with a known or later-recovered password, it's a durable account takeover that TOTP was meant to prevent.

### Summary A link-share token, the credential you hand out to let someone view a shared project, can call the v2 user-search endpoints, which it was never meant to reach. The v1 versions of the same endpoints correctly reject link-share tokens; the v2 versions don't. As a result, anyone with a share link can list every member of the shared project (and its parent projects), and can test whether any username exists anywhere on the instance. ### Details Two endpoints are affected: `GET /api/v2/projects/{id}/users/search` only checks project.CanRead, which a link share satisfies on its own project. With no parameter it returns the full user list, walking up the parent-project chain. `GET /api/v2/users?q=<name>` is a global search. It needs a query term, but any term works as an existence oracle: a hit confirms the username exists somewhere on the instance and returns the display name. Emails are correctly stripped from these responses, so the exposure is limited to identities (usernames and display names), but that's still an instance-wide directory that a share-link holder should never see. The fix is to resolve the caller with GetFromAuth in both handlers, so link-share tokens are rejected the same way v1 already rejects them. ### PoC 1. Get a link-share token. With any account that owns a project, create a read-only link share and note the hash, then exchange it: ``` POST /api/v1/shares/<hash>/auth {"password":""} ``` The response contains a token, a link-share JWT. 2. Confirm v1 blocks it (the fixed behavior). With that token: ``` GET /api/v1/projects/<id>/projectusers Authorization: Bearer <link_share_token> ``` → rejected: the token isn't a user token. 3. Now the vulnerable v2 endpoints, same token: ``` GET /api/v2/projects/<id>/users/search Authorization: Bearer <link_share_token> ``` → 200, full list of everyone with access to the project and its parents (id, username, name). ``` GET /api/v2/users?q=admin Authorization: Bearer <link_share_token> ``` → 200, a non-empty result confirms the username exists on the instance. Iterate q over a wordlist to enumerate accounts. ### Impact Information disclosure. A link share is a low-trust credential meant to expose one project's contents; here it also exposes the membership of that project's parents and lets the holder probe for any username across the whole instance. Since share links are often forwarded or semi-public, this hands an untrusted recipient a map of internal users and a username-validation oracle useful for phishing and credential stuffing. No account is required beyond possessing a share link. Emails are not exposed.

### Summary When you share a project with a team, the API lets you attach any team on the instance, including teams you have nothing to do with, as long as you're an admin of the project. Listing a project's teams then returns each team's full member roster. So any logged-in user can spin up a throwaway project, attach team IDs one by one, and read back the name, description, and complete member list of every team on the instance. Normally you can only see teams you belong to; this path ignores that. ### Details Sharing a project with a team is a two-step flow: you PUT a team to the project, then you GET the project's teams to see them. The share endpoint only enforces that you're an admin of the target project, it doesn't care whether the team you're referencing is one you're allowed to see. Any existing team ID is accepted. The listing endpoint is even more permissive: read access to the project is enough, which you obviously have on a project you created. And its response isn't just a list of team names, it includes each team's description, creator, and a full members array with every member's username, display name, and admin flag. Put together, an attacker who owns a single project can walk the team ID space and pull the roster of every team in the instance, including teams they aren't a member of. This contradicts how team visibility works everywhere else in the product, where you only ever see teams you belong to. Emails are stripped from the roster, so what leaks is identities and org structure rather than contact details. The fix is to require that the caller actually has access to the team they're attaching, not just to the project. ### PoC The attacker needs nothing but an ordinary account. 1. Create a throwaway project you own: 2. Attach team IDs one by one (sweep the range you want): ``` PUT /api/v1/projects/<your_project_id>/teams {<SNIP>, "team_id": <N>, <SNIP>} ``` 3. Read them back with their rosters: ``` GET /api/v1/projects/<your_project_id>/teams ``` Each entry contains the team name, description, creator, and a members array with every member's username, display name, and admin flag, for teams you are not a member of. ### Impact Information disclosure of the instance-wide team directory: team names, descriptions, and full membership, for teams the attacker has no relationship with. This maps out the organisation's group structure and who belongs where, useful for targeting and social engineering. Any authenticated account is enough; no share link, no admin rights, no victim interaction.

### Summary Vikunja lets you export your data as a zip and import it back. The import doesn't limit how large the archive expands to, how many files it contains, or how much storage one user can consume, and it appears to hold the whole archive in memory while processing it. Because the archive is compressed, a ~20 MB upload made of highly compressible content expands to tens of gigabytes once imported. A single crafted upload is enough to exhaust the server's memory or fill its disk and knock the whole instance offline. It can be repeated or run in parallel, since nothing stops a user from starting several imports at once. ### Details The import accepts an archive in the same layout the built-in export produces: a manifest describing projects and tasks, plus the attachment files those tasks reference. Each individual file inside the archive is size-checked, but there's no ceiling on the total uncompressed size or on the number of files, and there's no per-user storage quota anywhere. On top of that, the server seems to buffer every attachment in memory before writing it out, so the peak memory cost is the sum of all decompressed files at once, not one at a time. Compression is the key factor: a file full of a repeating byte (e.g. zeroes) shrinks by roughly a thousand to one. So an archive that fits under the upload size limit (around 20 MB) can describe on the order of a thousand ~20 MB attachments, which the server then expands to tens of gigabytes in RAM and writes to disk. When memory runs out the process is killed; when the disk fills, the instance (and anything else on that host) stops working. Nothing serialises imports, so a user can also fire several in parallel to reach the limit faster. The fix is to cap the total uncompressed size and the file count per archive, stream each file to disk instead of buffering them all in memory, enforce a per-user storage quota, and refuse a new import while one is already running for that user. ### PoC The attacker needs an ordinary account that can use the import feature. 1. Build a zip in the export format containing one project with for example ~200 tasks, each referencing an attachment, and ~200 attachment files, each 18 MB of zero bytes. Filled with zeroes, the whole thing compresses to roughly 4 MB (under the upload limit). ```python #!/usr/bin/env python3 import argparse, json, os, zipfile CHUNK = b"\0" * (1024 * 1024) def build(out, n, size, version): tasks = [{"title": f"t{i}", "attachments": [{"file": {"id": i, "name": "a"}}]} for i in range(1, n + 1)] data = json.dumps([{"title": "bomb", "tasks": tasks, "child_projects": []}]).encode() with zipfile.ZipFile(out, "w", zipfile.ZIP_DEFLATED, compresslevel=9) as z: z.writestr("VERSION", version) z.writestr("data.json", data) for i in range(1, n + 1): with z.open(f"files/{i}", "w") as f: for _ in range(size): f.write(CHUNK) raw = n * size * 1024**2 print(f"[+] {out}: {os.path.getsize(out)/1024**2:.2f} MiB " f"({raw/1024**3:.1f} GiB uncompressed)") p = argparse.ArgumentParser() p.add_argument("-o", "--out", default="bomb.zip") p.add_argument("-n", "--files", type=int, default=200) p.add_argument("-s", "--size-mib", type=int, default=18) p.add_argument("--version", default="v2.5.0") a = p.parse_args() build(a.out, a.files, a.size_mib, a.version) ``` 3. Upload it to the import endpoint: ``` PUT /api/v1/migration/vikunja-file/migrate (multipart file upload: the crafted zip) ``` 4. Watch the server. Memory climbs into 3.5 GB within seconds and the disk fills with the expanded files. On a typical host the process is OOM-killed or the disk fills, and the instance stops responding for everyone. Repeat, or send several uploads at once, to reach the limit reliably. (You can derive the exact archive layout in step 1 by first exporting your own data once and inspecting the zip it hands back.) ### Impact Denial of service (availability). One authenticated user, with a single upload, can drive the server into tens of GB of memory and disk usage, killing the process or filling the disk. This takes the whole instance down for every user, and if the disk is shared with other services on the host, those go down too. No admin rights and no victim interaction are required, any account that can import data is enough. Recovery needs an operator to reclaim memory/disk and clear the partially written import.

An open directory exposed on a server in Thailand revealed an active intrusion operation targeting two major broadband providers, primarily 3BB (Triple T Broadband). The attacker exploited CVE-2024-21762 to gain remote code execution on a FortiGate 60F SSL-VPN device. The exposed files included exploitation scripts, privilege escalation tools, brute-force utilities, and a MeshCentral agent configured as a persistent backdoor. The attacker aimed to extract subscriber authentication data from RADIUS databases and had valid OpenVPN certificates and active session cookies, indicating deep network access. The attacker also prepared cleanup scripts to remove traces while maintaining persistence. Hunt.io notified affected parties and CERT prior to public disclosure.

In the Linux kernel, the following vulnerability has been resolved: mm, swap: don't free a hibernation slot that is in the swap cache A slot with a folio in the swap cache is freed when the folio leaves the cache, not when its count drops. swap_put_entries_cluster() follows that rule. swap_free_hibernation_slot() does not, it calls __swap_cluster_free_entries() whether or not a folio sits on the slot. Cluster readahead can put one there. It walks a raw page_cluster sized window of offsets around the faulting entry, and a hibernation slot passes __swap_cache_add_check() because it is not a folio and its count is not zero. Freeing the slot then clears the entry under that folio. The folio is now unreachable from the swap table, and the offset goes back to the allocator. The folio is still on the LRU though, so reclaim can pick it up later. It then takes the old offset out of folio->swap and overwrites the table entry there, which by then may belong to someone else. This bug can trigger silent memory corruption, process crashes, or data instability across completely unrelated userspace applications - typically occurring when uswsusp is preparing the hibernation image. I found this while working on giving hibernation slots their own marker in the swap table, which I had discussed with Kairui. (https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/) As far as I know there are no reports, so there is no Reported-by/Closes to add. Check for a cached folio before freeing. The slot is then left in the ordinary state where only the swap cache holds it, and it is freed when the folio leaves the cache, either through the reclaim below or through normal reclaim later.