New OSTicket instance: Tickets not showing up for agent/Administrator

JRoemeth

Hi Everybody,
I have installed OSTicket via Plesk, running the following (Just realizing that that is a veeeeery old version of OSTicket, so this might be actually it):

Server Information
osTicket Version v1.12 (a076918) — Up to date
Web Server Software Apache
MySQL Version 10.3.36
PHP Version 5.4.16

(First of all, this is the first time I am doing anything related to being a Sysadmin, so it is possible I am just overlooking something super simple. Please also note that I am running it on Plesk, and have installed it similarly to how is it shown in this video: https://www.youtube.com/watch?v=GLq_d5GLplI With one key difference: The tickets just do not appear, neither when I use 'Agent view' as an admin, not when I use an actual Agent account. They appear in the statistics, and I can open them if I create them myself, but in the table they should show up when you klick on 'ticket's they just do not show up, neither in Chrome nor in Firefox (both on Mac OS)

I can of course provide Screenshots if needed. Do you think updating to a newer version would be likely to solve this?
Thank you very much,
Justus Römeth

KevinTheJedi

JRoemeth

Upgrade as soon as possible. 1.12.x is very old and is no longer supported. Meaning, if you were to have issues we wouldn't be able to assist. The latest supported releases are v1.17.5 and v1.18.1 (recommended). Note that both of these releases support PHP 8.1-8.2 only. v1.17.6 and v1.18.2 (coming soon) will support PHP 8.3 so stay tuned for that.
Sounds like the Admin doesn't have access to the Tickets' Department(s). In order for an Agent to see any Ticket they must either have access to the Department (either Primary access or Extended access), or they must be Assigned to the Ticket (either directly or one of their Teams), or they must be Referred to the Ticket (either directly, one of their Teams, or one of their Departments).

We do have a Documentation site that goes over all the settings, features, etc. that will help you in your osTicket journey:

https://docs.osticket.com/en/latest/index.html

Cheers.

cesa-mathew-page

Hi,
I noticed that there is a CVE for PHP.
Detail of vulnerability type:
PHP on Windows contains an argument injection vulnerability within the CGI module used by Apache web servers to run PHP code. When Unicode characters get converted to ASCII, PHP performs a best fit mapping and converts a special Unicode dash (0xAD) into an ASCII dash (0x2D). Apache escapes the dangerous 0x2D character, but not 0xAD. A malicious user is able to inject commands that are executed by PHP and run in the context of the web server. This has been patched in recent versions of PHP so that PHP no longer maps this value to a hyphen used by command line arguments.

So far, It is only believed to impact Windows systems and only those with the CGI module enabled. A PoC has been released and ransomware campaigns have been observed exploiting this in the wild.

Vulnerable Versions:
PHP 8.3.x before 8.3.8
PHP 8.2.x before 8.2.20
PHP 8.1.x before 8.1.29

Is there a roadmap/source files for PHP upgrade to 8.2.22?

Kind Regards

cesa-mathew-page

CGI and command line setups ¶

By default, PHP is built as both a CLI and CGI program, which can be used for CGI processing. If you are running a web server that PHP has module support for, you should generally go for that solution for performance reasons. However, the CGI version enables users to run different PHP-enabled pages under different user-ids.

Warning
A server deployed in CGI mode is open to several possible vulnerabilities. Please read our CGI security section to learn how to defend yourself from such attacks.
Testing ¶

If you have built PHP as a CGI program, you may test your build by typing make test. It is always a good idea to test your build. This way you may catch a problem with PHP on your platform early instead of having to struggle with it later.

Using Variables ¶

Some server supplied environment variables are not defined in the current » CGI/1.1 specification. Only the following variables are defined there: AUTH_TYPE, CONTENT_LENGTH, CONTENT_TYPE, GATEWAY_INTERFACE, PATH_INFO, PATH_TRANSLATED, QUERY_STRING, REMOTE_ADDR, REMOTE_HOST, REMOTE_IDENT, REMOTE_USER, REQUEST_METHOD, SCRIPT_NAME, SERVER_NAME, SERVER_PORT, SERVER_PROTOCOL, and SERVER_SOFTWARE. Everything else should be treated as 'vendor extensions'.

Just wondering whether the latest version osticket leverages these variables and is exposed to this PHP vulnerability?

KevinTheJedi

cesa-mathew-page

Uhhh, that would be a PHP thing and not osTicket. Simply upgrade PHP and you’re good.

Cheers.