MEDHOST Document Management System contains hard-coded credentials that are used for Apache Solr access. An attacker with knowledge of the hard-coded credentials and the ability to communicate directly with Apache Solr may be able to obtain or modify sensitive patient and financial information. The Apache Solr account name is dms. The password is hard-coded throughout the application, and is the same across all installations. Customers do not have the option to change passwords. The dms account for Apache Solr has access to all indexed patient documents.

Apache HTTP Server, in all releases prior to 2.2.32 and 2.4.25, was liberal in the whitespace accepted from requests and sent in response lines and headers. Accepting these different behaviors represented a security concern when httpd participates in any chain of proxies or interacts with back-end application servers, either through mod_proxy or using conventional CGI mechanisms, and may result in request smuggling, response splitting and cache pollution.

In Apache HTTP Server versions 2.4.0 to 2.4.23, malicious input to mod_auth_digest can cause the server to crash, and each instance continues to crash even for subsequently valid requests.

In Apache HTTP Server versions 2.4.0 to 2.4.23, mod_session_crypto was encrypting its data/cookie using the configured ciphers with possibly either CBC or ECB modes of operation (AES256-CBC by default), hence no selectable or builtin authenticated encryption. This made it vulnerable to padding oracle attacks, particularly with CBC.

A maliciously constructed HTTP/2 request could cause mod_http2 in Apache HTTP Server 2.4.24, 2.4.25 to dereference a NULL pointer and crash the server process.

In the XSS Protection API module before 1.0.12 in Apache Sling, the method XSS.getValidXML() uses an insecure SAX parser to validate the input string, which allows for XXE attacks in all scripts which use this method to validate user input, potentially allowing an attacker to read sensitive data on the filesystem, perform same-site-request-forgery (SSRF), port-scanning behind the firewall or DoS the application.

In the XSS Protection API module before 1.0.12 in Apache Sling, the encoding done by the XSSAPI.encodeForJSString() method is not restrictive enough and for some input patterns allows script tags to pass through unencoded, leading to potential XSS vulnerabilities.

Apache OpenMeetings 1.0.0 updates user password in insecure manner.

Apache OpenMeetings 1.0.0 responds to the following insecure HTTP methods: PUT, DELETE, HEAD, and PATCH.

Apache OpenMeetings 1.0.0 doesn't check contents of files being uploaded. An attacker can cause a denial of service by uploading multiple large files to the server.

Apache OpenMeetings 1.0.0 displays Tomcat version and detailed error stack trace, which is not secure.

Apache OpenMeetings 3.2.0 is vulnerable to parameter manipulation attacks, as a result attacker has access to restricted areas.

Apache OpenMeetings 1.0.0 is vulnerable to SQL injection. This allows authenticated users to modify the structure of the existing query and leak the structure of other queries being made by the application in the back-end.

Apache OpenMeetings 1.0.0 has an overly permissive crossdomain.xml file. This allows for flash content to be loaded from untrusted domains.

Apache OpenMeetings 1.0.0 uses not very strong cryptographic storage, captcha is not used in registration and forget password dialogs and auth forms missing brute force protection.

Apache OpenMeetings 1.0.0 is vulnerable to Cross-Site Request Forgery (CSRF) attacks, XSS attacks, click-jacking, and MIME based attacks.

Uploaded XML documents were not correctly validated in Apache OpenMeetings 3.1.0.

Both global and Room chat are vulnerable to XSS attack in Apache OpenMeetings 3.2.0.

The DiskFileItem class in Apache Wicket 6.x before 6.25.0 and 1.5.x before 1.5.17 allows remote attackers to cause a denial of service (infinite loop) and write to, move, and delete files with the permissions of DiskFileItem, and if running on a Java VM before 1.3.1, execute arbitrary code via a crafted serialized Java object.

The mod_dontdothat component of the mod_dav_svn Apache module in Subversion as packaged in Red Hat Enterprise Linux 5.11 does not properly detect recursion during entity expansion, which allows remote authenticated users with access to the webdav repository to cause a denial of service (memory consumption and httpd crash). NOTE: Exists as a regression to CVE-2009-1955.