Search: card-rn.ru

Wekan is open source kanban built with Meteor. From 9.57 until 9.74, the /api/boards/:boardId/exportExcel route in models/exportExcel.js called the asynchronous exporterExcel.canExport(user) authorization guard from models/server/ExporterExcel.js without awaiting it. The returned Promise was always truthy, so exporterExcel.build(res) ran even when board.isVisibleBy(user) would deny access, allowing any authenticated non-member to download private board card titles, descriptions, lists, swimlanes, members, and metadata. This issue is fixed in version 9.74.

Secure BootROM of RK3588s SoC is vulnerable to a time-of-check to time-of-use attack in case of booting from external media (SPI NOR or NAND, EMMC or SD). The code reads the header of the next-stage loader twice. The header contains hashes of the executable modules and is signed with a private key, the public part of which is verified against the SHA256 digest blown in the OTP. The first read is only partial and contains only the hashes of the executable modules. The second is complete, including the header signature. Although the header is verified based on the fully read data, the authenticity of the executable modules is checked against the partial data from the first read. An attacker with physical access to a device containing RK3588s SoC can easily modify the next-stage loader data on-the-fly using a low-cost SD-card or SPI NOR/NAND or EMMC emulator. Even a simple ultra low-cost circuit comprising two memory chips (containing the same data but different headers - the original and the modified one) and a multiplexer can be used to carry out an attack. This can lead to arbitrary code execution with the highest privileges available (EL3). This issue affects RK3588s: RK3588s SoC BootROM (secure) 350B20210512V100 and possibly others. As remediation apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable https://www.rock-chips.com/a/en/products/RK35_Series/2022/0926/1660.html

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: qcom: reject stream disable with no active interface handle_uaudio_stream_req() resolves an interface index with info_idx_from_ifnum(), which returns -EINVAL when no interface matches. The enable branch and the response: cleanup label both guard against a negative index, but the disable branch does not: it forms info = &uadev[pcm_card_num].info[info_idx] and dereferences it. uadev[].info is a pointer allocated only when a stream is first enabled, so a negative info_idx on the disable path is unsafe in two ways: - If the card was never enabled, .info is NULL and &info[-EINVAL] is a wild pointer; reading info->data_ep_pipe faults (kernel oops). - If the card was enabled at least once (.info allocated) and the disable names an interface that does not match, &info[-EINVAL] points before the allocation; info->data_ep_pipe / info->sync_ep_pipe are an out-of-bounds slab read and, when non-zero, an out-of-bounds 4-byte write (both pipe fields are cleared to 0). That is memory corruption, not just a NULL dereference. The request is reachable from unprivileged local userspace over AF_QIPCRTR. Reject a disable request with no resolved interface, matching the guard the enable path already has.

In the Linux kernel, the following vulnerability has been resolved: memstick: ms_block: reject a card that reports too many blocks msb_ftl_initialize() computes the zone count from the card block count with no bound: msb->zone_count = msb->block_count / MS_BLOCKS_IN_ZONE; ... for (i = 0; i < msb->zone_count; i++) msb->free_block_count[i] = MS_BLOCKS_IN_ZONE; msb->block_count is a card value. msb_read_boot_blocks() reads number_of_blocks from the card boot page and byte swaps it. free_block_count is a fixed int[MS_MAX_ZONES]. MS_MAX_ZONES is 16, so the valid indices are 0 to 15. The init loop above indexes it by zone_count. msb_mark_block_used() and msb_mark_block_unused() index it by pba / MS_BLOCKS_IN_ZONE, for pba up to block_count - 1. A card may report up to 65535 blocks. A block_count above 8192 (MS_MAX_ZONES * MS_BLOCKS_IN_ZONE) lets the pba index reach 16. That writes past free_block_count[] and corrupts struct msb_data. A larger count runs the init loop past the end too. A real Memory Stick has at most 16 zones. So it has at most 8192 blocks. msb_ftl_initialize() now rejects a card that reports more than MS_MAX_ZONES * MS_BLOCKS_IN_ZONE blocks.

Cisco Talos recently identified an undocumented phishing framework, internally branded "JWR" by its developer, built to convincingly impersonate checkout and login pages across major payment and shopping platforms. The client engine of the JWR phishing framework is a real-time, operator-driven system that, rather than merely logging form submissions like a static credential-stealing page, keeps an AES-CTR encrypted WebSocket open to the threat actor so they can steer each victim's session live. The victim data targeted by the actor using JWR extends well beyond payment data, encompassing identity documents, Social Security numbers, passport and driver's license images, website and PayPal credentials, 2FA codes, and full device fingerprints, all committed to the actor's server once a session ends. Talos assesses with medium confidence that the JWR phishing framework is a variant of "The Outsider," a phishing-as-a-service (PhaaS) platform, based on several similarities in the client engine scripts and functionalities of the two PhaaS platforms. Talos observed a real-world campaign delivering the JWR client via SMS lures impersonating toll authorities, and postal and courier services of several countries in Southeast Asia and the Middle East. JWR phishing framework, a likely variant of the Outsider JWR is a phishing framework capable of harvesting complete payment card data, login credentials, and personally identifiable information (PII) documents and images in real time. The client-side engine of the framework impersonates login, and checkout flows of several payment gateways, including Shopify, PayPal, Apple, Klarna, and banks, while allowing the operator to stealthily control the victim session through an AES-CTR encrypted WebSocket channel. The client engine architecture is divided into a Host Bridge module that relays commands into a phishing inline frame (iframe) and a Vue.js victim application that renders across 44 phishing pages, streams the victim's keystrokes to the actor as they are typed, and carries out more than 40 distinct instructions issued from the command-and-control (C2) console. The data exfiltration schema is a cvvform object that includes fields such as credit card number, CVV, PIN, expiry date, Social Security Number (SSN), passport or ID images, two-factor authentication (2FA) codes, website logins, PayPal credentials, and device fingerprint. Talos discovered that the JWR client engine shares significant code and functional similarities with the client of The Outsider PhaaS platform operated by the Chinese-speaking actor “Outsider Enterprise,” which was reported by external researchers . JWR client architecture and workflow Figure 1. JWR phishing framework’s client engine architecture and execution flow. The execution starts when the parent phishing webpage loads and executes the client's engine. It checks a single global flag, window.__HOST_MODE , which is set by the parent phishing page, and selects one of two execution modes. If the flag is set, the script enters Host Mode, and control passes to the Host Bridge module, an immediately invoked function expression (IIFE) that operates within the parent page, typically a replica of a legitimate checkout or account login page, relaying received details into a child iframe that contains the actual phishing form. It establishes a persistent WebSocket connection to the actor’s C2 server. If the flag is not set, the page enters Content Mode, and control passes to the Vue.js Application, an interactive front end that renders the phishing pages, collects victim input, manages the flow across 44 HTML files, and handles the actor’s instructions from the C2 server, ultimately redirecting to a custom error page after sending the data to the C2. The Content Mode of execution has three communication modes: standalone, pluginIframe, and hostIframe. In standalone mode, the application fully owns its WebSocket connection. In pluginIframe mode, it has no direct link to t…

The npm package 'cards-forms-clone-credit-clone' version 35.7.1 contains malicious code that downloads and executes platform-specific binaries from obfuscated external sources without verification. The package masquerades as a legitimate forms or credit card handling library but performs unauthorized code execution by writing and running downloaded executables in temporary directories.

Overview Two vulnerabilities in the REST API were found in Golf Compete foreUP. The first exposes the merchant, Finix, API credentials directly in customer record responses, allowing any user to obtain and use the payment processor account. The second is a missing object-level authorization check, which lets a user retrieve any other customer's full profile, payment token, and transaction history by changing the golfer_id in the request path. Description Golf Compete foreUP provides cloud-based golf course management software to over 2,000 golf courses. They offer tools that allow the management of customers, inventory, tee times, food & beverages, marketing, billing, etc. The vulnerabilities identified are listed below. CVE-2026-15657 A vulnerability in the foreUP customer REST API exposes merchant credentials. Each customer record response includes the facility’s merchant API credentials in cleartext, exposing the following details: finix_username finix_password finix_merchant_id Merchant credentials are identical across for customers at the same facility and are actively used by the backend to register new payment instruments. Any authenticated customer can obtain the facility’s merchant credentials when querying own record. Combined with the second vulnerability described below, an attacker can retrieve merchant credentials from any customer record at the facility. CVE-2026-15658 A missing object-level authorization also known as BOLA (Broken Object Level Authorization) and IDOR (Insecure Direct Object References) in the REST API endpoint returns the record identified by golfer_id without verifying ownership. A caller can substitute any golfer_id while using their own valid JSON Web Token (JWT) and receive another customer's full profile, including the following details: Name, email, phone numbers, date of birth, address Free‑text household relationship notes Finix payment‑instrument tokens Dwolla bank funding‑source tokens Billing and transaction history Impact With a single valid low‑privilege foreUP customer account, someone can perform the following actions: 1. Retrieve any customer’s full profile and contact data 2. Access stored card tokens and Dwolla ACH funding-source tokens 3. Enumerate and view full billing and transaction history for any customer 4. Obtain live Finix merchant API credentials for the facility Also, because the web API is shared by all tenants, all facilities using foreUP are affected, meaning that a customer from facility A could query merchant information from facility B. Solution On 07/26/2026, foreUP confirmed that all vulnerabilities in this report have been remediated. Users should remain aware of increased phishing and identity theft risks and monitor their accounts for suspicious activity. Acknowledgements Thank you to Eric Mead for reporting this vulnerability. This document was written by Bob Kemerer. Vendor Information One or more vendors are listed for this advisory. Please reference the full report for more information. References https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/ https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/02-API_Broken_Object_Level_Authorization https://portswigger.net/web-security/access-control/idor https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References Other Information CVE IDs: CVE-2026-15657 CVE-2026-15658 Date Public: 2026-07-30 Date First Published: 2026-07-30 Date Last Updated: 2026-07-30 15:12 UTC Document Revision: 1 About vulnerability notes Contact us about this vulnerability Provide a vendor statement

In the Linux kernel, the following vulnerability has been resolved: ALSA: usx2y: us144mkii: fix work UAF on disconnect tascam_disconnect() cancels capture_work and midi_in_work before usb_kill_anchored_urbs() kills the capture/MIDI-in URBs. Those URBs self-resubmit, and their completion handlers reschedule the work. A URB that completes in the small window between cancel_work_sync() and usb_kill_anchored_urbs() therefore re-arms the work after its only cancel. Nothing cancels it again before snd_card_free() frees the card-private tascam structure, so the work handler then runs on freed memory. Kill the anchored URBs before cancelling the work; once the work is cancelled no remaining URB can complete to re-arm it.

The `actionRenderCardPreview()` method in `FieldsController` passes the `fieldLayoutConfig` POST parameter directly to `Fields::createLayout()` without calling `Component::cleanseConfig()`. This allows Yii2 event handler injection via `on eventName` keys in the config array, leading to arbitrary code execution. This is the same vulnerability pattern that was fixed in GHSA-4484-8v2f-5748 (same file, `_fldComponent` method correctly uses `cleanseConfig`), GHSA-qx2q-q59v-wf3j (EntryTypesController), and GHSA-2fph-6v5w-89hh (ElementIndexesController). ## PoC As an admin user with a valid session: ``` POST /admin/actions/fields/render-card-preview HTTP/1.1 Content-Type: application/x-www-form-urlencoded Cookie: CraftSessionId=<session> fieldLayoutConfig[on+init]=phpinfo&CRAFT_CSRF_TOKEN=<token> ``` When the FieldLayout object is constructed, Yii2 processes the `on init` key as an event handler registration. During `Component::init()`, the `init` event is triggered, calling `phpinfo()`. The phpinfo output (which includes environment variables, potentially containing database credentials and `CRAFT_SECURITY_KEY`) will appear in the response. ## Impact An authenticated admin can achieve RCE through Yii2 event handler injection. While this requires admin access (same as GHSA-4484-8v2f-5748, which was rated moderate), it allows arbitrary PHP function execution and information disclosure via phpinfo.

Anki is a program for creating and reviewing flashcards. Prior to 25.09.4, Anki's webview-based pages communicate with the Rust backend using an internal localhost API, and user scripts included via iframes in the editor can access this API despite protections intended to block reviewer and editor scripts. A malicious imported card package with an embedded iframe can use exposed API methods such as getImageForOcclusion to read arbitrary files accessible to the Anki process and exfiltrate them over the network. This issue is fixed in version 25.09.4.

An active SMS phishing campaign targets Serbian road users by impersonating Putevi Srbije, Serbia's state road authority. Victims receive text messages claiming they have unpaid traffic fines with urgent payment demands. The fraudulent links lead to cloned government websites designed to steal payment card details. The infrastructure employs JavaScript-based obfuscation techniques to evade automated security scanners and uses disposable domains with uncommon TLDs. Technical analysis reveals connections to both Darcula and Phoenix Phishing-as-a-Service platforms, indicating fraudsters are combining tools from multiple PhaaS vendors. The operation demonstrates coordinated roles including infrastructure setup, SMS distribution, and data harvesting. Similar campaigns have targeted victims globally across government bodies, postal services, and financial institutions.

Phishing#phoenix#government impersonationSerbia

Threat actors are exploiting anticipation for the FIFA World Cup 2026 through sophisticated phishing campaigns targeting fans seeking tickets, hospitality packages, and tournament information. Attackers have deployed FIFA-themed domains and mobile-optimized phishing infrastructure resolving to specific IP addresses, designed to harvest credentials and payment information. The campaigns feature convincing fake ticketing portals that mimic official FIFA services, collecting personal details including names, emails, phone numbers, and payment card data. Some variants redirect victims to online gambling platforms after credential theft. The infrastructure leverages third-party payment services like KOIpay and EBpay, with JavaScript redirecting users to external payment gateways. Victims face risks including fraudulent account creation, credential stuffing attacks, email account takeover, and unauthorized financial access. This operation represents part of a larger fraud ecosystem targeting the tournament.

Ghost is a Node.js content management system. From 6.19.4 until 6.21.1, when re-rendering posts, Ghost would refetch missing image dimensions by issuing an outbound HTTP request to the URL stored on an image card — without restricting that URL to trusted image hosts. An authenticated staff user able to create or edit posts could therefore point an image card at an attacker-chosen host and cause the Ghost server to request it on their behalf, including hosts on internal networks or cloud instance metadata endpoints that would not normally be reachable from the public internet. This vulnerability is fixed in 6.21.1.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet(). Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released. The issue was identified through static analysis.

The Zephyr ext2 filesystem driver (subsys/fs/ext2) trusted the on-disk directory entry fields de_rec_len and de_name_len when walking a directory block. ext2_fetch_direntry() guarded only with de_name_len > EXT2_MAX_FILE_NAME, but de_name_len is a uint8_t and EXT2_MAX_FILE_NAME is 255, so the check is always false; the function then memcpy'd up to 255 name bytes and the lookup/readdir paths advanced traversal by an unvalidated de_rec_len. Each directory block is read into a block_size-sized slab buffer, and block_off can be driven near the block end by preceding entries' rec_len, so the 8-byte header read and the subsequent name memcpy can read up to ~263 bytes past the end of the block buffer into adjacent heap/slab memory. On the readdir path those bytes are returned to the caller in fs_dirent.name, leaking adjacent kernel heap memory; a de_rec_len of 0 also causes a zero-progress infinite loop (denial of service), and the unlink path's memmove(de, next, next_reclen) over unvalidated records is an additional OOB read/write source. The defect is reached by any path-based operation (open, stat, unlink, rename, mkdir) or directory listing on a mounted ext2 volume, so a crafted or corrupted ext2 image on attacker-supplied storage (SD card, USB mass storage, or otherwise mounted image) triggers it. Affected: Zephyr ext2 from its introduction in v3.5.0 through v4.4.0. The fix validates rec_len and name_len in the parser and rejects entries whose header does not fit the remaining block or whose rec_len crosses the block boundary in every traversal caller.

On May 15, 2026, Huntress agents detected an intrusion where threat actors compromised a terminal server to stage a massive phishing campaign rather than deploy ransomware. The attacker used legitimate bulk email software (Gammadyne Mailer) with a project file named 'dracii' (Romanian for 'the devils') and six recipient lists containing 8,894,920 email addresses. Operating from Romanian IP addresses, the actor impersonated UK pharmacy chain Boots through a fake customer satisfaction survey designed to harvest personal and payment card data. The phishing kit was hosted on a compromised Bolivian government website (ipelc.gob.bo), which Huntress reported to Bolivia's national CSIRT. The campaign used direct-to-MX delivery to bypass mail relays, with the mailer configured to send from 666 threads simultaneously. Evidence suggests this Romanian operator has been running multiple UK-targeting campaigns since at least July 2025, rotating between retail, tax, and cryptocurrency themes.

A user reported encountering a browser security warning indicating an invalid or untrusted certificate on a medical bill payment website (mdpaybill.net). The user was forced to bypass this security warning to complete a payment using their credit card. This situation raises concerns about the security and trustworthiness of the payment site, potentially exposing sensitive financial information.

A sophisticated Chinese-origin fraud operation is targeting FIFA World Cup 2026 attendees through pixel-perfect website clones and a multi-tenant phishing infrastructure. The actors deploy typosquatted domains and a commercially developed administrative system to mimic legitimate FIFA ticketing platforms. Technical analysis reveals high-fidelity brand cloning, real-time card skimming capabilities, and a distributed reseller ecosystem supporting at least 15 active operator instances. The platform functions as an active Man-in-the-Middle framework intercepting payment card details and bypassing SMS-based two-factor authentication in real time. Traffic is primarily driven through Facebook and Instagram in-app browsers. Simplified Chinese localizations and operator geolocations from IP addresses in China indicate PRC-based actors. The core payment routing hub tbpay[.]uk lacks financial regulatory authorization and has historical malicious patterns.